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EXECUTIVE  SUMMARY 


The  Adaptive  Architectures  for  Command  and  Control  (A2C2)  project  is  a  four-year 
research  effort  sponsored  by  the  Office  of  Naval  Research.  It  involves  researchers  at  the 
Naval  Postgraduate  School  (NPS),  the  University  of  Connecticut,  Michigan  State 
University,  George  Mason  University,  Alphatech  Inc.,  Aptima  Inc.,  and  several  other 
institutions.  The  research  focuses  on  organizational  adaptation  in  joint  command  and 
control  organizations,  exploring  how,  why,  and  when  organizations  adapt  or  should  adapt 
their  structures,  what  skills,  training,  and  technology  are  required  to  support  that 
adaptation,  and  developing  computer  aids  to  help  custom  design  organization  structures 
for  specific  missions.  The  project  consists  of  field  research,  computer  modeling,  and  a 
series  of  human-in-the-loop  experiments. 

The  A2C2  project  uses  a  multi-player  real-time  simulation  environment  capable  of  : 

•  Focusing  on  the  dynamic  execution  of  the  combatant  phases  of  the  mission 

•  Allowing  researchers  to  easily  manipulate  key  task  structure  variables  and 
available  resources  and  organizational  structures. 

The  approach  taken  combines  analytical  and  empirical  efforts  to  develop  a  model- 
test-model  paradigm  of  experimentation  with  human  teams.  A  first  step  in  this  process 
was  to  abstract  "real  world"  problems  in  order  to  bring  them  into  a  controlled  laboratory 
environment  where  we  could  control  a  large  variety  of  experimental  conditions  while 
manipulating  independent  variables  of  interest  in  order  to  measure  their  effects  on  the 
dependent  variable  used  to  test  the  hypotheses  of  interest. 

The  first  experiment,  conducted  at  NPS  in  March  1996,  served  as  a  baseline  and  test- 
run  of  the  DDD-IE  simulation.  The  second  experiment  built  on  the  findings  of  the  first  to 
explore  the  interaction  between  task  structure  and  organizational  structure  and  drivers  of 
adaptation  in  an  organization.  This  thesis  focuses  on  the  objectives  of  the  A2C2  project  in 
general  and  the  specific  details  of  the  second  NPS  experiment  conducted  12-26 
November  1996.  Emphasis  is  on  the  resources,  scenario,  and  tasks  designed  to  support 
the  experiment  and  hypotheses  selected  by  the  A2C2  research  team. 

To  design  the  scenario  for  the  second  NPS  A2C2  experiment,  a  visual  representation 
of  a  task's  structure  was  developed  using  the  task  structure  diagram  methodology 
developed  by  Michael  Berigan  in  NPS  experiment  one. 

A  literature  review  which  defines  the  dimensions  of  task  structure  applicable  to  this 
project  (uncertainty,  time  pressure,  complexity,  coordination  requirements,  magnitude, 
resources  required,  information  required,  task  formalization,  and  dynamicity)  and 
describes  the  task  structure  diagram  is  provided  in  the  second  chapter. 

Once  the  dimensions  of  task  structure  are  defined  and  a  grading  scale  developed,  an 
explanation  of  a  task  structure  diagram  is  given.  Many  dimensions  of  task  structure  are 
represented  directly  in  this  diagram;  others  can  be  inferred  from  it.  The  task  structure 
diagram  method  allows  experimenters  to  ensure  a  task  accomplishes  the  objectives  that 
have  been  set,  provides  a  straightforward,  visual  method  for  comparing  it  with  other 
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tasks,  and  describes  a  task  to  those  outside  the  task  design  process. 

The  task  design  process  is  then  used  to  describe  the  second  NPS  A2C2  experiment. 
The  dimension  of  interest  was  determined  by  the  definitions  of  dimensions  of  task 
structure  given  previously,  initial  A2C2  field  research,  and  results  from  the  first  NPS 
A2C2  experiment.  The  task  structure  dimension  of  interest,  coordination  requirements, 
was  selected  as  the  independent  variable  and  introduced  at  two  levels:  high  internal 
coordination  and  high  external  coordination  over  shared  resources.  The  scenario  used  for 
A2C2  field  research  and  the  first  NPS  experiment  provides  the  foundation  for  the  second 
experiment.  The  next  step  is  to  design  the  scenario  tasks,  develop  an  organizational 
structure  and  provide  data  to  UCONN  modelers  as  input  to  their  model-based  optimized 
organizational  structure. 

Designing  the  experiment,  required  resolution  of  several  issues: 

•  How  to  measure  performance  of  organizations  in  order  to  compare  their 
performance  when  using  different  organizational  structures  to  perform  the  same 
tasks.  Two  task  structures  were  used  to  examine  whether  interactions  between 
task  and  organizational  structures  exists. 

•  How  to  inject  internal  and  external  stimuli,  that  were  essentially  equivalent  in 
terms  of  the  task  load  to  resource  ratio,  into  the  scenario  to  induce  adaptation  in 
the  organizations.  An  internal  stimuli  is  a  change  to  resources  or  capabilities  of 
the  organization.  An  external  stimuli  is  a  change  in  the  environment  or  mission. 

Of  interest  in  the  second  experiment,  with  regard  to  organizational  structure,  were  the 
performance  of  the  model-based  and  operational  organization  structures  and  the  designs 
of  those  dynamically  selected  by  the  subjects  during  the  planning  sessions.  This  interest 
results  in  the  following  research  questions: 

1.  Does  the  performance  of  the  model-based  design  organization  match  the  model's 
predictions  of  performance? 

2.  In  the  face  of  an  internal  "trigger",  do  teams  adapt  by  changing  architectures? 

3.  In  the  face  of  an  external  "trigger",  do  teams  adapt  by  changing  architecture? 

4.  Do  organizations  adapt  their  organizational  structures  based  on  changes  in  mission 
task  and  resources  available? 

5.  Why  and  how  do  organizations  adapt? 

6.  Are  some  organizations  better  able  to  accommodate  changes  to  mission  or 
resources  without  a  drop  in  performance  than  others?  Are  some  organizations  more 
robust  than  others?  If  so,  why? 

7.  Can  the  model-based  organizational  structures  developed  by  the  modelers  at 
UCONN,  based  on  task  structure  and  available  resources,  perform  as  well  or  better  than 
those  developed  using  the  current  method  of  selecting  organizational  structures  used  by 
operational  commanders,  as  measured  by  performance,  resources  utilization,  mission 
accomplishment,  and  losses? 

Finally,  a  description  of  the  experiment,  including  setup,  discussion  of 
operationalization  of  the  scenarios  and  organizational  structures,  training  conducted  with 
the  subjects,  conduct  of  the  experiment  itself,  and  lessons  learned  from  the  experiment 
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with  regard  to  scenario  design  is  provided.  A  brief  overview  of  the  preliminary  findings 
from  the  data,  summary  of  the  thesis  and  future  areas  of  research  complete  the  paper. 
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I.    INTRODUCTION 

A.         THE  A2C2  PROGRAM 

The  Adaptive  Architectures  for  Command  and  Control  (A2C2)  Project  is  a 
continuing  effort  to  examine  adaption  in  joint  command  and  control  organizations.  Rapid 
advances  in  communications  technology  and  computers  have  made  real-time  command 
and  control  (C2)  possible.  This  revolution  in  C2  capability  will  soon  provide  decision 
makers  (DMs)  in  a  joint  military  organization  with  an  unparalleled  tactical  and  strategic 
picture  of  the  battlefield.  A  current  area  of  focus  within  the  Department  of  Defense  (DoD) 
is  organization  of  the  force.  New,  highly  evolved  organizational  concepts  are  considered 
one  of  the  "enablers  of  the  revolution  in  military  affairs"  (Joint  War  fighting  Center, 
1995).  The  Joint  Staff's  C4I  for  the  Warrior  (C4IFTW)  concept,  Copernicus,  Sea  Dragon, 
and  other  service  initiatives  that  reside  within  the  overarching  C4IFTW  concept  call  for 
flattened  command  structures.  These  flattened  command  structures  will  allow  U.S.  forces 
to  begin  achieving  more  efficient  use  of  enhanced  sensor-to-shooter  communications 
capabilities  and  dominant  battle  space  knowledge.  Decision  makers  (DMs)  will  have  the 
ability  to  rapidly  access  all  information  available  within  the  organization,  monitor  actions 
made  by  other  DMs,  and  call  upon  a  world-wide  data  base  to  aid  in  the  combat  decision 
process.  This  powerful,  "omnipotent"  capability  has  been  dubbed  "Global 
Awareness"(Joint  War  fighting  Center,  1995). 

Researchers  at  the  Naval  Postgraduate  School,  the  University  of  Connecticut, 
George  Mason  University,  Michigan  State  University,  Alphatech  Inc.,  and  Aptima  Inc. 
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have  theorized  that  the  most  capable  organizations  will  respond  by  adapting  their 
structures  and  processes  from  traditional,  rigid  hierarchical  organizational  structures  into 
more  flexible,  network-like  architectures  to  take  advantage  of  the  opportunities  presented 
by  enhanced  sensor-to-shooter  communications  capabilities  and  dominant  battle  space 
knowledge. 

Current  research  involving  adaptive  architectures  for  joint  C2  seeks  to  examine 
the  interactions  between  mission  requirements  and  organizational  structure.  The  Office 
of  Naval  Research  (ONR),  in  the  summer  of  1995,  commissioned  a  four- year  research 
effort  into  this  far-reaching  topic  -  the  A2C2  project.  This  project  is  exploring  the 
changes  in  task  structure,  mission,  and  resources  that  drive  changes  to  organizational 
structure  in  the  joint  warfare  environment,  and  how  the  joint  organization  should  adapt. 

The  A2C2  project  is  a  national  joint  effort  by  researchers  from  academia, 
(University  of  Connecticut  (UCONN), George  Mason  University(GMU),  Michigan  State 
University  (MSU)),  government  agencies  (Naval  Postgraduate  School,  (NPS)),  industry 
research  activities  (Alphatech  Inc.,  Aptima  Inc.),  and  other  institutions.  The  project's 
goals  are  to  advance  the  state  of  knowledge  regarding  decision  making  performance  in 
joint  organizational  settings,  to  better  understand  how,  why,  and  when  organizations 
adapt  or  should  adapt  to  a  changing  environment,  and  if  the  changes  result  in  improved 
organization  performance,  to  develop  the  skills,  training,  and  technology  required  to 
support  that  adaptation  (Alphatech/UCONN/NPS,  1995,  p.  2).  The  researchers  will  make 
use  of  organizational  theory,  organizational  models,  simulated  combat  experiments  with 
military  officers,  and  field  observation  with  experienced  operational  commanders  in  an 


iterative  process  to  expand  this  body  of  knowledge.  The  A2C2  project  is  moving  through 
several  phases.  In  late  1995,  the  data  collection  process  began  with  field  research,  visits  to 
military  organizations,  participation  in  demonstrations  and  wargames,  and  a  round  of 
structured  interviews  with  experienced  commanders  from  all  branches  of  the  U.S.  Armed 
Forces. 

The  purpose  of  the  field  research  was  to  identify  potential  drivers  of  adaptation  in 
joint  operations,  from  the  perspective  of  commanders  experienced  in  joint  operations,  and 
to  raise  the  specific  issues  that  should  be  addressed  in  the  project's  later  experiments. 
"Drivers  of  adaption"  is  a  phrase  used  to  describe  changes  in  mission  tasks,  resources, 
technology,  etc.  that  cause  an  organization  to  adjust  its  structure  or  functionality  for 
improved  performance. 

After  the  field  interviews,  the  A2C2  researchers  began  a  series  of  experiments 
using  war  games  and  simulations  of  increasing  complexity  and  fidelity.  Each  experiment 
builds  upon  the  field  research,  insights  gained  from  modeling,  and  previous  experiments. 

The  approach  taken  combines  analytical  and  empirical  efforts  in  a  model— test- 
model  paradigm  featuring  experimentation  with  human  teams.  A  first  step  in  this  process 
was  to  abstract  "real  world"  problems  in  order  to  bring  them  into  a  controlled  laboratory 
environment  where  a  large  variety  of  experimental  conditions  could  be  controlled  while 
manipulating  independent  variables  of  interest  in  order  to  measure  their  effects  on  the 
dependent  variable  used  to  test  the  hypotheses  of  interest.  In  order  to  conduct  the 
empirical  research,  the  A2C2  project  requires  a  multi-player  real-time  simulation 
environment  capable  of : 


•  Focusing  on  the  dynamic  execution  of  the  combatant  phases  of  the  mission 

•  Allowing  researchers  to  easily  manipulate  key  task  structure  variables  and 
available  resources  and  organizational  structures. 

The  Distributed  Dynamic  Decisionmaking  (DDD-HI)  paradigm  was  used  as  the 
simulation  environment  for  both  the  first  and  second  NPS  experiments.  This  third- 
generation  simulation  is  an  evolution  of  an  earlier  version  developed  by  UCONN 
(DDD-II),  which  was  used  extensively  to  conduct  empirical  research  from  1989  -  1995 
involving  "open-ocean"  naval  team  (distributed)  decisionmaking  and  coordination. 
(Higgins,  1996) 

B.         PURPOSE  OF  THE  THESIS 

This  thesis  will  discuss  the  objectives  of  the  A2C2  project  in  general  and  the 
specific  details  of  the  second  NPS  experiment  conducted  12-26  November  1996. 
Emphasis  is  on  the  resources,  scenario,  and  tasks  designed  to  support  the  experimental 
design,  goals,  and  hypotheses. 

To  make  this  thesis  a  stand-alone  document,  several  chapters  from  Michael 
Berigan's  thesis,  which  focused  on  the  first  A2C2  experiment,  will  be  included  to  provide 
background  information. 


C.         THESIS  OUTLINE 

This  paper  consists  of  seven  chapters  and  two  appendices. 

•  Chapter  II  is  an  overview  and  review  of  those  portions  of  Michael 
Berigan's  thesis  on  the  first  NPS  experiment  which  are  applicable  to  this 
paper. 

•  Chapter  HI  develops  the  methodology  used  to  design  the  scenario  and 
provide  the  inputs  needed  by  UCONN  for  generating  the  model-based 
organizational  structure. 

•  Chapter  IV  uses  the  methodology  developed  by  Berigan  to  develop  the 
task  structure,  describes  the  scenario  and  the  organizational  structures, 
provides  details  of  the  processes  used  in  developing  the  organizations,  and 
gives  an  overview  of  the  conduct  of  experiment  two. 

•  Chapter  V  is  an  overview  of  preliminary  findings  from  experiment  two. 
The  findings  are  beyond  the  designed.scope  of  the  thesis,  but  are  included 
for  completeness  and  closure  in  order  to  lay  a  foundation  for  the  research 
plan  for  NPS  experiment  three  in  November  1997. 

•  Chapter  VI  details  some  modifications  to  the  DDD  simulation  made  for 
the  second  experiment,  preliminary  plans  for  additional  improvements, 
and  lessons  learned. 

•  Chapter  VII  is  a  summary  of  the  paper  and  areas  of  future  research. 

•  Appendix  A  provides  the  operational  orders  and  order  modifications  used 
for  training  and  briefing  the  players  and  the  quick  reference  sheets  used 


during  the  DDD-EH  runs. 

Appendix  B  provides  the  data  collection  forms  and  player  questionnaires. 


II.  DEFINING  DIMENSIONS  OF  INTEREST 


A.  INTRODUCTION 

To  determine  which  types  of  organizations  function  best  with  different  classes  of 

tasks  it  is  necessary  to  develop  an  organized  and  disciplined  method  to  differentiate 
between  tasks  and  organizations  to  ensure  they  are  different.  To  differentiate  between 
tasks,  they  must  be  characterized.  This  can  be  accomplished  by  decomposing  each  task 
into  the  lower  levels  of  its  various  dimensions.  What  are  the  dimensions  of  task  structure? 
Little  in  the  literature  of  organizational  theory  and  behavioral  decision  theory  explains  or 
defines  dimensions  of  task  structure.  Discussions  of  one  or  several  aspects  of  task 
structure  are  common  (Wood,  1986,  Campbell,  1988,  Malone  and  Crowston,  1994,  Ben 
Zur  and  Breznitz,  1981,  Davis  et  al.,  1991,  Evaristo  et  al.,  1995),  but  none  provided  a 
comprehensive  exposition  of  these  dimensions  as  they  pertain  to  the  A2C2  experiments 
until  Michael  Berigan  discussed  them  in  his  thesis  in  1996.  Since  I  relied  on  his  work  in 
this  particular  area,  I  will  include  the  applicable  portions  of  chapter  II  from  his  thesis 
here  to  provide  the  necessary  background  information. 

B.  LITERATURE  REVIEW 

The  following  pages  are  an  excerpt  from  Michael  Berigan's  thesis.  The  work  was 
the  basis  on  which  the  tasks  for  the  second  experiment  were  designed. 

The  literature  on  dimensions  of  task  structure  is  mainly  composed  of 
articles  and  papers  from  technical  journals.  The  works  described  below  are  the 


most  significant  to  date  from  the  perspective  of  enumerating  dimensions  of  task 
structure.  Six  articles  are  discussed:  Wood  (1986)  and  Campbell  (1988)  deal  with 
complexity,  Malone  and  Crowston  (1994)  consider  coordination  requirements, 
Ben  Zur  and  Breznitz  (1981)  deal  with  time  pressure,  Evaristo  et  al.  (1995) 
describe  time  pressure  and  uncertainty,  and  Davis  et  al.  (1991)  discuss  task 
activities,  time  frame,  task  formalization,  task  ambiguity,  task  complexity  (using 
Wood's  (1986)  definition),  and  task  significance. 

(1)        Wood 

Robert  E.  Wood,  in  his  article,  "Task  Complexity:  Definition  of  the 
Construct"  (1986),  first  states  that  tasks  contain  three  components:  (1)  the 
product,  or  what  is  produced  by  completing  the  task;  (2)  acts,  or  things  that  must 
be  done  in  order  to  complete  the  task;  and  (3)  information  cues,  or  information 
that  provides  the  stimulus  for  performance  of  a  task,  or  is  required  for  the  task  to 
be  completed.  He  then  defines  task  complexity  in  terms  of  these  three  task 
components,  and  decomposes  task  complexity  into  three  different  components: 
component  complexity,  coordinative  complexity,  and  dynamic  complexity,  and 
discusses  methods  for  quantifying  each  of  the  components. 

(i)         Component  Complexity 

Component  complexity  is  a  direct  function  of  the  number  of 
distinct  acts  that  must  be  completed  in  the  performance  of  the  task  and  the  number 
of  distinct  information  cues  that  must  be  processed  in  order  to  perform  the  acts. 
Wood  gives  the  sum  TC,,  the  measure  of  component  complexity,  as  the  sum  of 
information  cues  for  all  acts  of  all  subtasks  within  the  task.  [Berigan,  1996) 

In  experiment  two,  the  level  of  component  complexity  at  the  micro  level  remained 

approximately  the  same  as  in  experiment  one,  a  detailed  description  of  the  scenario  for  the 

second  experiment  is  contained  in  Chapter  IV.  At  the  macro  level,  many  more  task  items 

were  inserted  into  the  scenario  to  increase  the  workload  of  all  the  decision  makers.  The 

purpose  was  to  place  a  premium  on  resource  utilization  either  by  reducing  existing  resources 

or  increasing  the  required  tasks. 

(ii)        Coordinative  Complexity 

Coordinative  complexity,  as  defined  by  Wood,  refers  to  the 
relationships  between  task  inputs  and  task  products.  It  describes  the  form  and 
strength  of  the  relationships  between  information  cues,  acts,  and  products,  as  well 
as  the  sequencing  of  inputs.  Wood  gives  a  number  of  different  indices  with  which 
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to  attempt  to  measure  coordinative  complexity,  most  of  which  are  a  bit  obscure 
and  difficult  to  obtain,  and  I  will  not  elaborate  on  them  because  of  the  space  that 
would  require.  The  most  straightforward  is  the  sum  of  all  precedence  relations 
between  each  act  and  all  other  acts  in  the  task,  which  he  denotes  TC2.  [Berigan, 
.  1996) 

We  significantly  increased  the  level  of  coordinative  complexity  in  experiment  two; 

the  capabilities  of  the  various  platforms  were  modified  such  that  many  different  possible 

combinations  could  be  used  to  accomplish  a  given  task  or  operation,  but  in  many  instances 

more  than  one  platform  and/or  decision  maker  would  need  to  coordinate  efforts  to  bring 

sufficient  assets  to  bear. 


(1)  Dynamic  Complexity 

Wood  defines  dynamic  complexity  as  changes  in  the  task 
environment  which  affect  the  relationships  between  task  inputs  and  products.  He 
measures  this  by  summing  the  changes  in  TC,  and  TC2  over  discrete  time  periods, 
reduced  by  the  change  multiplied  by  a  predictability  coefficient  for  each  time 
period,  to  arrive  at  a  dynamic  complexity  figure  denoted  TC3. 

(2)  Total  Complexity 

To  arrive  at  a  figure  for  total  complexity,  Wood  obtains  a  weighted 
sum  of  the  TC,,  TC2,  and  TC3  totals.  The  specific  weights,  represented  by 
coefficients,  assigned  to  each  sum  would  be  situationally  dependent,  constrained 
by  the  requirement  that  TC,  be  more  heavily  weighted  than  TC2,  and  TC2  more 
heavily  weighted  than  TC3. 

i.  Campbell 

Donald  J.  Campbell,  in  his  article  "Task  Complexity:  A  Review  and 
Analysis"  (1988),  took  a  different  approach  to  defining  complexity.  He  posited 
that  task  complexity  is  closely  related  to  information,  and  that  any  task  attributes 
that  increase  the  load,  diversity,  or  rate  of  change  of  information  should  be 
considered  contributors  to  task  complexity.  He  found  four  task  characteristics  that 
meet  that  criterion:  the  degree  to  which  a  task  contains  multiple  paths,  multiple 
outcomes,  conflicting  interdependence  among  paths,  and  uncertain  or 
probabilistic  linkages. 

(a)        Multiple  Paths 

Increasing  the  number  of  possible  ways  to  complete  a  given  task 
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increases  the  complexity  of  the  task.  This  is  particularly  true  if  the  paths  vary  in 
their  "goodness,"  that  is,  some  paths  more  efficiently  or  effectively  complete  the 
task  than  others.  Complexity  is  reduced  if  all  paths  presented  are  of  equal 
goodness. 

(b)  Multiple  Outcomes 

Outcomes  are  the  different  results  the  performer  of  the  task  wants 
to  achieve  when  the  task  is  completed.  The  greater  the  number  of  different 
outcomes,  the  more  complex  the  task. 

(c)  Conflicting  Interdependence  Among  Paths 

Campbell  defines  this  as  negative  relationships  among  desired 
outcomes.  If  achieving  one  outcome  conflicts  with  achieving  another  outcome, 
task  complexity  increases. 

(d)  Uncertain  or  Probabilistic  Linkages 

Campbell  defines  linkages  as  the  connection  between  potential 
path  activities  and  desired  task  outcomes.  If  there  is  difficulty  determining  these 
linkages,  or  the  linkages  have  a  probability  of  less  than  one,  information 
processing  requirements  are  increased  significantly,  and  task  complexity 
increases. 

ii.         Malone  and  Crowston 

Thomas  W.  Malone  and  Kevin  Crowston,  in  their  paper  "The 
Interdisciplinary  Study  of  Coordination"  (1994)  define  coordination  as  managing 
dependencies  between  activities.  They  defined  four  different  types  of 
dependencies  that  could  need  to  be  managed:  shared  resources, 
producer/consumer  relationships,  simultaneity  constraints,  and  task/subtask 
relationships. 

(1)  Managing  Shared  Resources 

Whenever  more  than  one  actor  or  activity  requires  a  limited 
resource,  coordination  is  required  to  ensure  that  the  resource  is  properly  allocated 
among  the  actors  or  activities. 

(2)  Managing  Producer/Consumer  Relationships 

A  producer/consumer  relationship  is  one  in  which  one  actor  or 
activity  produces  something  that  is  used  by  another  actor  or  activity. 


(3)        Managing  Simultaneity  Constraints 

Simultaneity  constraints  occur  where  more  than  one  activity  must 
be  performed  at  the  same  time  as  another,  or  when  one  activity  must  be  performed 
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at  a  specific  time  in  relation  to  the  performance  of  another  activity. 

(4)        Managing  Task/Subtask  Relationships 

Task/subtask  relationships  occur  when  a  task  must  be  broken  up 
into  multiple  subtasks,  and  the  subtasks  divided  up  among  multiple  actors  or 
different  time  periods  for  completion. 

iii.        Davis,  Collins,  Eierman,  and  Nance 

Gordon  Davis,  Rosann  Webb  Collins,  Michael  Eierman,  and  William 
Nance,  in  their  working  paper  "Conceptual  Model  for  Research  on  Knowledge 
Work"  (1991)  discuss  characteristics  of  task  environment  that  apply  to  knowledge 
tasks  rather  than  manual  tasks.  They  came  the  closest,  of  any  work  with  which  I 
am  familiar,  of  attempting  to  somewhat  comprehensively  enumerate  dimensions 
of  task  structure,  although  I  do  not  believe  that  their  enumeration  is  complete,  or 
that  they  even,  in  some  cases,  considered  the  right  dimensions.  However,  some  of 
the  characteristics  they  describe  are  quite  useful.  They  discuss  six  characteristics: 
task  activities,  time  frame,  task  formalization,  task  ambiguity,  task  complexity, 
and  task  significance,  of  which  formalization,  ambiguity,  and  complexity  are  the 
most  suitable  for  the  purposes  of  this  thesis. 

(1)  Task  Activities 

Davis  et  al.  define  task  activities  as  the  operations  that  must  be 
implemented  to  complete  a  task,  with  each  activity  being  associated  with  one  or 
more  problem  spaces. 

(2)  Time  Frame 

The  amount  of  time  it  will  take  to  complete  a  task. 

(3)  Task  Formalization 

The  authors  consider  task  formalization  to  be  the  level  of 
specification  and  structure  that  is  imposed  on  the  performance  of  the  task,  or  task 
inputs  or  outputs.  A  task  with  high  formalization  would  be  described  in  a  very 
structured  way;  there  are  certain  well-defined  activities  that  must  be  performed  in 
a  explicit  order  to  complete  the  task.  In  a  task  with  low  formalization,  though,  the 
activities  required  to  complete  the  task,  and  even  the  goals  of  the  task,  would  be 
poorly  defined  and  open  to  interpretation. 


(4)  Task  Ambiguity 

Task  ambiguity  is  defined  as  the  clarity  of  understanding  of  the 
activities  that  are  required  to  complete  a  task,  or  of  the  inputs  or  outputs  of  a  task. 

(5)  Task  Complexity 
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The  authors  use  Wood's  (1986)  definition  of  complexity. 

(6)        Task  Significance 

Task  significance  is  defined  as  the  value  of  the  task  output  to  the 
organization  performing  the  task,  and  the  interdependency  between  task  outputs 
and  other  operations  of  the  organization. 

iv.         Evaristo,  Adams,  and  Curley 

Roberto  Evaristo,  Carl  Adams,  and  Shawn  Curley,  in  their  article 
"Information  Load  Revisited:  A  Theoretical  Model"  (1995)  describe  three  task 
characteristics:  time  pressure,  task  formalization,  and  task  complexity.  The 
authors  define  time  pressure  as  the  time  available  to  perform  the  task,  and  reiterate 
Davis  et  al.'s  (1991)  definition  of  task  formalization  and  Wood's  (1986) 
definition  of  task  complexity.  Their  most  interesting  contribution  is  their 
description  of  uncertainty,  although  they  do  not  consider  it  a  task  characteristic, 
but  an  information  characteristic.  They  define  uncertainty  as  knowledge 
inadequacy,  resulting  in  an  actor's  inability  to  predict  something  accurately.  They 
further  cite  the  sources  of  uncertainty  as  unavailability  or  incompleteness  of 
information,  low  information  reliability,  and  information  novelty. 

v.         Ben  Zur  and  Breznitz 

Hasida  Ben  Zur  and  Shlomo  J.  Breznitz,  in  their  article  "The  Effect  of 
Time  Pressure  on  Risky  Choice  Behavior"  (1981)  define  time  pressure  as  the 
amount  of  information  that  must  be  considered  and  processed  during  one  time 
unit,  or  as  the  time  allotted  for  processing  a  fixed  amount  of  information.  Their 
definition  refers  to  time  pressure  in  the  information  domain,  but  it  could  be 
generalized  to  include  the  task  domain  as  well.  [Berigan,  1996) 


C.         DIMENSIONS  OF  TASK  STRUCTURE 

Dimensions  of  task  structure  are  the  characteristics  which  describe  and  identify  a  task. 
To  define  the  dimensions  of  task  structure  that  are  of  interest  in  the  A2C2  experiment,  nine 
dimensions  are  detailed:  uncertainty,  time  pressure,  complexity,  coordination  requirements, 
magnitude,  resources  required,  information  required,  task  formalization,  and  dynamicity. 
Ideally,  these  dimensions  should  be  orthogonal,  but  complete  orthogonality  would  require  a 
comprehensiveness  that  is  beyond  the  scope  of  the  experiment  at  this  phase  in  the  A2C2 
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project.  As  a  result,  there  are  some  interactions  between  dimensions.  For  each  dimension  of 
task  structure,  a  definition  and  an  example  in  an  operational  military  context  are  given, 
followed  by  a  description  of  how  any  given  task  could  be  graded  in  that  dimension. 

vi.        Uncertainty 

(1)  Definition 

Uncertainty  is  defined  as  the  degree  to  which  information  about 
states,  inputs,  outcomes,  or  environments  of  tasks  is  unknown  (Evaristo,  et  al.,  p. 
200). 

(2)  Levels 

This  dimension  is  difficult  to  quantify,  and  grading  must  be  done 
on  a  subjective  basis.  There  are  a  number  of  ways  to  subjectively  grade 
dimensions,  which  will  be  used  throughout  this  chapter.  First,  anchored  scales  can 
be  used.  Anchored  scales  are  scales  of  measurement  (from  0  to  100,  for  example) 
in  which  illustrations  are  given  of  a  task  that  would  be  graded  ("anchored")  at 
various  points  on  the  scale,  typically  the  high  and  the  low  ends.  For  example,  if 
"uncertainty"  was  graded  using  an  anchored  scale,  an  event  of  which  absolutely 
no  information  about  states,  inputs,  outcomes,  or  environments  was  known  would 
be  considered  a  "0,"  and  an  event  about  which  all  information  about  states,  inputs, 
outcomes,  or  environments  was  known  would  be  considered  a  "100."  The  benefit 
of  an  anchored  scale  is  that  it  allows  for  a  moderate  amount  of  transportability, 
that  is,  tasks  that  are  not  necessarily  being  evaluated  in  terms  of  one  another  and 
are  otherwise  dissimilar  can  be  compared  using  a  well-anchored  scale.  Another 
option  for  subjectively  grading  dimensions  is  to  use  a  scale  such  as  High, 
Medium,  Low,  and  None.  This  scale  would  be  adequate  in  circumstances  where 
the  only  comparison  of  tasks  that  is  of  interest  is  between  two  or  more  tasks  that 
are  generally  being  evaluated  in  terms  of  one  another,  and  are  otherwise  similar. 
Grading  using  this  scale  is  rather  arbitrary,  depending  on  the  grader's  definition  of 
the  level,  so  its  transportability  is  low. 


(3)        Example 

A  simple  example  of  uncertainty  would  involve  an  AW  ACS 
operator  dealing  with  unknown  air  tracks.  Since  the  identification  and  intentions 
of  the  aircraft  are  not  known  (incomplete  information  on  states,  inputs,  and 
environments),  the  AW  ACS  operator  is  unsure  whether  to  direct  that  the  aircraft 
be  shot  down,  warn  it  away,  or  let  it  continue  what  it  is  doing  (incomplete 
information  on  outcomes).  This  task  would  be  graded  as  Medium  or  High 
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uncertainty. 

vii.       Time  Pressure 

(1)  Definition 

Time  pressure  is  the  amount  of  activity  that  must  be  completed 
within  a  given  amount  of  time  (Ben  Zur  and  Breznitz,  1981,  p.  89).  Alternately,  it 
could  be  defined  as  the  degree  to  which  an  individual  or  group  performing  a  task 
are  stressed  by  the  requirement  to  complete  the  task  within  a  given  amount  of 
time.  I  chose  time  pressure  as  a  dimension  rather  than  Davis  et  al.'s  (1991)  task 
characteristic  "time  frame,"  because  time  frame  does  not  take  into  account  the 
magnitude  of  the  task  at  hand,  while  time  pressure,  being  measured  as  a  rate,  does. 

(2)  Levels 

Time  pressure  could  be  either  represented  using  a  subjective  scale, 
such  as  High,  Medium,  Low,  or  None,  or  an  anchored  scale,  or  a  more  objective, 
quantitative  scale,  depending  on  the  variation  of  the  above  definition  that  is  being 
used.  A  subjective  scale  would  suggest  itself  if  comparing  two  or  more  dissimilar 
tasks,  and  the  only  information  the  researcher  is  interested  in  is  whether  there  is 
time  pressure  on  the  task  performer  to  complete  the  task  within  a  certain  period  of 
time,  and  what  the  relative  levels  between  the  two  or  more  tasks  are.  A 
quantitative  scale  would  suggest  itself  when  comparing  tasks  which  are  similar  in 
most  dimensions.  Time  pressure  could  then  be  represented  as  the  number  of 
activities  or  subtasks  that  must  be  completed,  divided  by  the  time  available  to 
complete  the  task.  This  method,  unfortunately,  requires  a  standard  definition  of 
activity  or  subtask,  both  in  magnitude  and  duration.  If  two  tasks  are  equal  in  the 
quantitative  measure  of  time  pressure  described  above,  but  one  task's  subtasks  or 
activities  take  significantly  longer  to  perform  than  the  other  task's,  then  the 
quantitative  scale  is  inappropriate.  In  situations  where  the  grader  cannot  with 
confidence  equate  the  subtasks  or  activities  of  one  task  with  those  of  another,  time 
pressure  should  be  graded  using  the  subjective  scale. 

(3)  Example 

An  example  of  time  pressure  from  the  Persian  Gulf  conflict  is  a 
mobile  SCUD  missile  launcher,  spotted  setting  up  and  preparing  to  fire.  The 
identification  information  must  be  passed  from  the  sensor  to  a  control  agency  with 
the  assets  on  hand  to  destroy  the  launcher,  an  asset  must  be  assigned  to  destroy  the 
launcher,  the  asset  must  travel  to  the  launcher,  and  the  asset  must  destroy  the 
launcher,  all  in  a  matter  of  a  few  minutes1.  This  task  has  High  time  pressure,  on  a 
subjective  scale.  On  an  objective  scale,  if  identifying,  passing  information, 


i 


This  was  rarely,  if  ever,  successfully  done  during  the  Persian  Gulf  conflict. 
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assigning  an  asset,  getting  in  position  to  attack,  and  attacking  are  all  considered 
subtasks,  and  the  time  available  is  10  minutes,  then  time  pressure  is  5/10  or  0.5 
subtasks  per  minute. 

viii.       Complexity 

I  chose  a  variation  on  Campbell's  (1988)  definition  of  complexity  over 
Wood's  (1986),  for  several  reasons.  First,  Campbell's  four  characteristics  of 
complexity  are  more  easily  understood  than  Wood's  three  components  of 
complexity,  and  are  more  simply  measurable.  Second,  Wood's  description  of 
coordinative  complexity  is  very  close  to  Malone  and  Crowston's  (1994)  definition 
of  coordination,  which  I  chose  to  include  as  a  separate  dimension  listed  in 
paragraph  four  below.  Finally,  Wood's  concept  of  dynamic  complexity  can  (be) 
generalized  to  all  dimensions  of  task  structure,  not  just  complexity,  and  it  is 
included  as  dynamicity,  in  paragraph  nine  below. 

Complexity,  then,  can  be  defined  as  the  degree  to  which  a  task  contains 
five  task  characteristics:  multiple  attributes,  multiple  paths,  multiple  outcomes, 
conflicting  interdependence  among  outcomes,  and  uncertain  or  probabilistic 
linkages  (Campbell,  1988,  p.  43).  Multiple  attributes  has  been  added  to 
Campbell's  original  list  of  four  characteristics  on  the  basis  of  other  articles. 
Specific  definitions  of  the  five  task  characteristics  are  as  follows: 

(1)  Multiple  Attributes 

(a)     Definition.  The  number  of  attributes  that  a  task  performer 
must  take  into  account,  or  more  than  one  thing  that  must  be  taken  into 
consideration  in  order  to  complete  the  task,  directly  affect  task  complexity.  The 
more  attributes  a  task  has,  the  more  complex  it  is. 

(b)     Levels.  Multiple  attributes  is  graded  by  the  number  of 
attributes  that  must  be  taken  into  consideration. 

(2)  Multiple  Paths 

(a)  Definition.  The  number  of  paths  that  could  be  taken  to 
arrive  at  a  desired  outcome  (Campbell,  1988,  p.  43). 

(b)  Levels.  This  aspect  of  complexity  is  graded  by  the 
approximate  number  of  paths  that  could  be  taken  to  arrive  at  the  desired  end  state. 
In  many  cases,  this  number  could  be  infinite,  or  approach  infinity.  When  this  is 
true,  the  evaluator  should  only  count  the  major  variations  of  paths. 

(3)     Multiple  Outcomes 

(a)     Definition.  The  number  of  outcomes  desired  from  a  task. 
These  outcomes  need  not  be  mutually  exclusive  (Campbell,  1988,  p.  43). 
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(b)  Levels.  This  aspect  is  graded  by  the  number  of  different 
outcomes  that  the  task  performer  needs  to  achieve. 

(4)  Conflicting  Interdependence  Among  Outcomes 

(a)  Definition.  Conflicting  interdependence  among 
outcomes  is  a  negative  relationship  between  desired  outcomes.  If  achieving  one 
desired  outcome  conflicts  with  achieving  another  desired  outcome,  complexity 
increases  (Campbell,  1988,  p.  44). 

(b)  Levels.  Conflicting  interdependence  among  outcomes 
can  be  graded  by  counting  the  number  of  conflicts  between  instances  of 
subparagraph  (c)  above.  Each  conflict  should  then  be  given  a  grade  of  1  if  the 
conflict  is  minor,  2  if  it  is  moderate,  and  3  if  it  is  severe,  or  some  similar  scale. 
These  grades  should  then  be  totaled  across  all  conflicts  so  that  each  task  has  a 
single,  numerical  grade. 

(5)  Uncertain  or  Probabilistic  Linkages 

(a)  Definition.  The  condition  where  the  connection  between 
the  potential  path  activities  and  the  desired  outcomes  from  a  task  are  uncertain,  or 
probabilistic  (Campbell,  1988,  p.  45). 

(b)  Levels.  High,  Medium,  Low,  or  None. 

(6)  Example 

A  good  general  example  of  complexity  is  the  conduct  of  an 
amphibious  assault.  The  amphibious  assault  task  contains  multiple  attributes 
(terrain,  hydrography,  enemy  positions,  roads,  beaches,  enemy  reinforcement 
capability,  etc.)  One  desired  outcome  of  the  task  is  to  destroy  or  suppress  enemy 
positions  at  or  near  the  beachhead.  There  are  several  ways  to  do  this  (MULTIPLE 
PATHS),  such  as  to  use  close  air  support,  naval  gunfire,  infiltrate  SEAL  or 
reconnaissance  teams,  or  some  combination.  There  are  also  many  additional 
outcomes  (MULTIPLE  OUTCOMES)  that  are  desired,  such  as  to  achieve  surprise 
and  minimize  casualties.  However,  achieving  surprise  and  destroying  and 
suppressing  enemy  positions  are  usually  mutually  exclusive  (CONFLICTING 
INTERDEPENDENCE  AMONG  PATHS)  —  if  the  commander  precedes  his 
amphibious  assault  with  a  heavy  air  and  sea  bombardment,  he  will  stand  a  good 
chance  of  destroying  or  suppressing  the  enemy  positions,  but  he  will  probably 
destroy  the  element  of  surprise.  Finally,  if  the  enemy's  positions  at  or  near  the 
beach  are  well  protected  and  disguised,  the  commander  is  uncertain  whether  his 
possible  actions  of  close  air  support,  naval  surface  fire  support,  etc.  will  be  able  to 
successfully  achieve  his  desired  outcome  of  suppressing  or  destroying  the  enemy 
positions  (UNCERTAIN  OR  PROBABILISTIC  LINKAGES). 
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This  example  would  be  graded  as  follows: 

(a)  Multiple  Attributes:  The  task  attributes  that  must  be 
considered  in  an  amphibious  assault  are  objective,  time  available,  terrain,  weather, 
hydrography,  friendly  forces  available,  enemy  positions,  enemy  reinforcements, 
enemy  air  threat,  enemy  sea  threat,  enemy  anti-air  threat,  beaches,  mobility  on 
land,  and  non-combatants,  for  a  total  of  14.  These  are  very  high-level  attributes,  so 
it  would  be  inappropriate  to  compare  this  task  with  a  task  in  which  the  attributes 
were  low-level. 

(b)  Multiple  Paths:  The  number  of  paths  that  could  be 
taken  to  conduct  an  amphibious  assault  is  infinite.  They  can  be  categorized  into 
major  variations,  however.  The  major  paths  that  could  be  taken  are  to  conduct  the 
assault  (as  an  across-the-beach  assault,  vertical  envelopment,  or  combination) 
with  extensive  air  and  naval  surface  fire  support  beach  preparation,  conduct  the 
assault  without  extensive  air  and  naval  surface  fire  support  beach  preparation, 
conduct  the  assault  while  destroying/suppressing  enemy  positions  using  stealthy 
means  (SEAL/Recon  teams/Information  Warfare),  or  any  of  the  three  previously 
mentioned  paths,  plus  a  feint  at  a  different  location,  for  a  total  of  6  possible  major 
paths. 

(c)  Multiple  Outcomes:  High-level  desired  outcomes  for 
the  given  amphibious  assault  task  are  to  (a)  accomplish  the  objective,  (b)  achieve 
surprise,  (c)  suppress  enemy  positions  at  the  beach,  (d)  minimize  casualties,  (e) 
interdict  enemy  reserves,  (f)  achieve  sea  supremacy,  (g)  achieve  air  superiority, 
and  (h)  minimize  collateral  damage,  for  a  total  of  8  desired  outcomes. 

(d)  Conflicting  Interdependence  Among  Outcomes: 
Conflicts,  and  the  scores  for  each,  are  shown  in  Table  1  (correlate  letters  on  table 
with  outcomes  listed  in  paragraph  above).  It  should  be  noted  that  the  scoring  in 
Table  1  is  situationally  dependent;  conflicts  between  outcomes  would  vary  in 
different  amphibious  operations. 
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Table  1.  Scoring  of  Conflicting  Interdependence  Among  Outcomes,  Where  Each 
Entry  On  Table  Represents  The  Conflict  Between  The  Outcomes  Represented  in 
Column  i  and  Row  j 
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(e)    Uncertain  or  Probabilistic  Linkages:  Depending  on  the 
situation  and  the  accuracy  and  volume  of  intelligence  available,  this  could  vary 
from  low  to  high. 

ix.  Coordination  Requirements 

(1)  Definition 

Generally,  coordination  requirements  is  the  degree  to  which 
dependencies  between  activities  must  be  managed  (Malone  and  Crowston,  1994, 
p.  90).  This  can  be  subdivided  into  external  (the  group  with  others)  and  internal 
(among  members  of  the  group)  coordination.  Four  different  types  of  dependencies 
that  must  be  coordinated,  and  an  example  of  each,  are  as  follows: 

(a)  Shared  Resources.  Who,  among  a  group  of  actors,  gets 
which  available  and  common  resources  (Malone  and  Crowston,  1994,  p.  92). 

(b)  Producer/Consumer  Relationships.  When  one  member 
of  a  group  uses  the  output  of  another,  or  a  member  of  a  group  or  the  group  as  a 
whole  uses  the  output  of  another  entity,  or  this  other  entity  uses  the  group's  or  a 
member  of  the  group's  output  (Malone  and  Crowston,  1994,  p.  93). 

(c)  Simultaneity  Constraints.  When  two  or  more  activities 
must  be  scheduled  or  synchronized  (Malone  and  Crowston,  1994,  p.  95). 

(d)  Task/Subtask.  Goal  selection  and/or  task  decomposition 
within  a  group  and/or  among  groups  (Malone  and  Crowston,  1994,  p.  95). 

(2)  Levels 

A  task  would  be  given  a  grade  for  each  of  the  four  different  types 
of  dependencies  listed  above,  and  on  both  the  internal  and  external  level. 
Subjective  grades  such  as  High,  Medium,  Low,  and  None  are  probably  most 
appropriate.  Thus,  each  task  would  have  eight  coordination  requirements  grades 
associated  with  it. 

(3)  Example 

(a)  Shared  resources:  Two  light  infantry  units  each  face  an 
enemy  armored  threat,  and  there  is  only  one  section  of  antitank  helicopters  that 
can  be  used  against  those  threats,  and  it  is  attached  to  one  of  the  infantry  units. 
Coordination  required  would  be  graded  as  High  (internal)  and  Low  (external).  If 
the  antitank  helicopter  asset  is  owned  by  an  external  agent,  however,  coordination 
required  would  be  graded  as  Low  (internal)  and  High  (external). 

(b)  Producer-consumer  relationships:  During  the  conduct  of 
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an  amphibious  assault,  mine  clearing  helicopters  must  be  used  to  clear  mines  from 
the  approach  to  the  landing  beach.  The  landing  force,  then,  is  the  consumer  of  the 
mine  clearing  helicopters'  output.  If  we  consider  the  "group"  to  be  the  amphibious 
task  force,  then  coordination  required  would  be  High  (internal)  and  Low 
(external).  If  we  consider  the  "group"  to  be  the  landing  force,  however,  then 
coordination  required  would  be  Low  (internal)  and  High  (external). 

(c)  Simultaneity  constraints:  During  the  latter  stages  of  the 
same  amphibious  assault,  an  infantry  unit  must  conduct  an  attack  synchronized 
with  close  air  support  and  naval  surface  fire  support.  If  the  "group"  was 
considered  to  be  the  amphibious  task  force,  the  coordination  required  would  be 
High  (internal)  and  Low  (external).  If  the  "group"  was  considered  to  be  the 
landing  force,  the  coordination  required  would  be  Low  (internal)  and  High 
(external). 

(d)  Task/Subtask:  A  landing  force  commander  is  given  a 
mission  of  taking  a  specific  objective.  He  must  then  divide  the  task  up  into 
subtasks  for  his  subordinate  units  to  complete.  The  coordination  required  in  this 
situation  would  be  High  (internal)  and  Low  (external). 

x.  Magnitude 

(1)  Definition 

The  magnitude  of  a  task  is  the  number  of  activities  or  subtasks  that 
must  be  performed  in  order  to  complete  the  task. 

(2)  Levels 

The  magnitude  of  a  task  could  be  determined  quantitatively  by  the 
number  of  activities  that  must  be  performed  in  order  to  complete  the  task. 
However,  this  requires  a  standardized  definition  of  "activity,"  such  that  one 
activity  is  as  difficult  to  perform  as  another,  and  decomposition  of  the  task  to  the 
point  where  all  activities  are  identified.  Another  way  to  assess  the  magnitude  of  a 
task  would  be  to  use  an  anchored  scale.  For  example,  magnitude  could  be 
measured  on  a  one  to  one  hundred  scale,  with  "one"  representing  the  task  of 
pressing  the  space  bar  on  a  typewriter,  and  "one  hundred"  representing  the  task  of 
constructing  the  United  States  Interstate  Highway  System. 

(3)  Example 

The  task  of  conducting  an  amphibious  assault  has  many  different 
activities  or  subtasks  that  must  be  performed,  such  as  clearing  the  beach,  making  a 
reconnaissance,  suppressing  artillery  with  close  air  support,  et  cetera.  On  the  one 
to  one  hundred  scale  mentioned  above,  the  score  would  be  about  30  for  a 
significant  amphibious  assault. 
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xi.  Resources  Required 

(1)  Definition 

Resources  required  to  complete  a  task  is  defined  as  the  resources 
other  than  information  that  the  actors  must  possess  in  order  to  successfully 
complete  the  task  in  question. 

(2)  Levels 

Resources  required  could  be  measured  quantitatively  by  the 
number  of  resources  required  to  complete  a  task,  or  could  be  graded  on  a 
subjective  "High,  Medium,  and  Low"  scale.  As  is  the  case  with  magnitude,  one 
must  take  care  to  ensure  that  there  is  a  standard  definition  of  resource,  so  that  five 
resources  in  one  instance  is  the  same  as  five  resources  in  another. 

(3)  Example 

A  landing  force  is  given  the  mission  of  attacking  an  objective,  and 
that  objective  requires  three  infantry  companies  to  effectively  overwhelm  it.  If  the 
"base  unit"  of  resources  is  one  infantry  company  equivalent,  then  resources 
required  to  complete  this  task  is  three. 

xii.  Information  Required 

(1)  Definition 

Information  required  to  complete  a  task  is  the  information  that  the 
actors  must  possess  in  order  to  successfully  complete  the  task  in  question. 

(2)  Levels 

Information  required  is  measured  using  the  same  method  as 
resources  required. 

(3)  Example 

A  Silkworm  anti-ship  missile  site  threatens  an  aircraft  carrier  battle 
group.  However,  it  was  reported  in  a  residential  area,  so  additional  information 
(confirmation  and  precise  location  via  U-2  imagery)  is  required  before  the 
commander  can  destroy  that  threat.  If  the  base  unit  of  information  is  one 
intelligence  report,  then  information  required  to  complete  this  task  is  two  reports, 
the  initial  report  and  the  confirmation  report. 

xiii.  Task  Formalization 

(1)  Definition 

Task  formalization  is  the  level  of  specification  and  structure 
exhibited  by  the  task  (Davis  et  al.,  1991,  p.  22).  A  task  with  high  formalization  is 
defined  in  a  very  structured  way;  there  are  certain  well-defined  activities  that  must 

21 


be  performed  in  a  definite  sequence  in  order  to  complete  the  task.  In  a  task  with 
low  formalization,  though,  the  activities  required  to  complete  the  task,  and 
possibly  even  the  goals  of  the  task,  are  poorly  defined  and  open  to  interpretation. 

(2)  Levels 

This  dimension  is  again  quite  subjective,  and  the  levels  should 
probably  be  High,  Medium,  Low,  and  None,  or  some  other  discrete  scale. 

(3)  Example 

The  task  of  calling  for  artillery  fire  against  a  visible  target  is  very 
well  structured.  There  are  precise  procedures  that  the  forward  observer  must 
follow,  using  specific  radio  nets  and  message  formats,  that  are  ingrained  from  his 
earliest  training.  Task  formalization  for  an  artillery  call  for  fire  is  High.  However, 
the  task  of  infiltrating  enemy  lines  and  destroying  a  prepared  defensive  position  is 
not  well  structured  —  there  are  many  ways  that  the  task  could  be  carried  out,  and 
the  methods  used  and  paths  taken  are  not  well  formalized,  but  situationally 
dependent.  Task  formalization  for  the  infiltration  task  is  Low. 

xiv.  Dynamicity 

(1)  Definition 

The  dynamicity  of  a  task  is  the  degree  to  which  one  or  more  of  the 
dimensions  of  the  task  changes  over  time.  Dynamicity  could  refer  to  any  of  the 
dimensions  described  above,  alone  or  in  combination  with  others. 

(2)  Levels 

This  is  quite  subjective,  and  would  probably  best  be  graded  as 
High,  Medium,  Low  or  None  in  each  dimension,  or  possibly  the  number  of 
changes  per  unit  time  in  each  dimension,  if  that  is  measurable. 

(3)  Example 

Returning  to  our  amphibious  assault  example,  consider  the  task  of 
conducting  the  assault  across  the  beach.  If  the  assault  was  conducted  while  the 
amphibious  task  force  was  still  over  the  horizon,  and  retained  the  element  of 
surprise,  the  task  would  be  much  different  than  if  it  was  conducted  later,  when  the 
amphibious  task  force  was  in  view  of  the  objective  beach,  and  the  element  of 
surprise  was  lost.  The  later  it  was  conducted,  the  better  prepared  the  enemy  would 
be  for  the  assault.  In  each  dimension,  dynamicity  is  graded  as  follows: 

Uncertainty:  High  (The  later  the  assault  is  conducted,  the 

less  uncertainty) 

Time  Pressure:    High  (The  later  the  assault  is  conducted,  the 

more  time  pressure) 

Complexity:  High  (The  later  the  assault  is  conducted,  the 

more  complexity) 
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Coordination  Requirements:  High  (The  later  the  assault  is 

conducted,  the  more  coordination  required) 

Magnitude:  High  (The  later  the  assault  is  conducted,  the 

greater  the  magnitude) 

Resources  Required:  High  (The  later  the  assault  is  conducted, 

the  more  resources  required) 

Information  Required:  High  (The  later  the  assault  is 

conducted,  the  more  information  required) 

Task  Formalization:  Low  [Berigan,  1996) 


D.         EXCEPTIONS  TO  ORTHOGONALITY 

The  dimensions  discussed  are  distinct,  but  related.  If  we  can  identify  the 

interrelationships  between  the  dimensions,  we  can  compensate  for  the  interaction  by 

preventing  variations  from  occurring  in  those  dimensions  the  experimenter  desires  to  hold 

constant.  Not  all  the  dimensions  interact  with  each  other,  Berigan  listed  those  dimensions 

that  should  have  little  or  no  interaction,  and  then  discussed  how  changes  in  one 

dimension  may  affect  some  or  all  of  the  other  dimensions. 

There  should  be  little  or  no  interaction  between  uncertainty  and 
dynamicity,  time  pressure  and  dynamicity,  complexity  and  dynamicity, 
coordination  requirements  and  task  formalization,  coordination  requirements  and 
dynamicity,  magnitude  and  task  formalization,  magnitude  and  dynamicity, 
resources  required  and  task  formalization,  resources  required  and  dynamicity, 
information  required  and  task  formalization,  information  required  and  dynamicity, 
or  task  formalization  and  dynamicity.  All  other  interactions  are  detailed  below. 

xv.  Uncertainty-Time  Pressure 

As  uncertainty  increases,  the  number  of  activities  that  an  actor  would  have 
to  perform  in  order  to  deal  with  the  uncertainty  well  enough  to  complete  the  task 
could  also  increase  (increased  magnitude).  If  this  number  of  activities  increases 
while  the  time  allowed  to  perform  the  task  remains  constant,  time  pressure  will 
increase.  Conversely,  if  time  pressure  increases,  it  could  force  the  actor  to 
complete  the  task  before  he  is  able  to  obtain  all  the  information  he  wants,  thus 
increasing  uncertainty. 

xvi.  Uncertainty-Complexity 
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As  uncertainty  increases,  complexity  can  also  increase.  The  number  of 
attributes  that  must  be  taken  into  account  in  order  to  reduce  uncertainty  can 
increase,  thus  causing  greater  complexity.  Additionally,  if  the  uncertainty 
decreases  the  probability  of  the  linkages  between  path  activities  and  desired 
outcomes,  this  can  cause  an  increase  in  complexity.  Conversely,  if  the  complexity 
increases,  it  should  not  necessarily  affect  the  uncertainty. 

xvii.  Uncertainty-Coordination  Requirements 

Changes  in  uncertainty  can  cause  changes  in  coordination  requirements.  If 
uncertainty  increases,  whether  resources  must  be  shared,  which  activities  must  be 
simultaneous,  what  must  be  produced  and  consumed,  or  which  subtasks  are 
required  in  the  performance  of  a  task  can  also  become  more  uncertain,  requiring 
greater  coordination  for  any  type  of  dependency  in  which  the  uncertainty  is 
increased.  Conversely,  changes  in  coordination  requirements  should  not  cause 
changes  in  uncertainty. 

xviii.  Uncertainty-Magnitude 

As  mentioned  under  "time  pressure,"  as  uncertainty  increases,  the  number 
of  activities  that  an  actor  must  perform  in  order  to  alleviate  the  uncertainty  could 
increase,  thus  increasing  the  magnitude  of  the  task.  Conversely,  an  increase  in 
magnitude  could  force  the  actor  to  complete  the  task  before  he  is  able  to  obtain  all 
the  information  he  wants,  thus  increasing  uncertainty. 

xix.  Uncertainty-Resources  Required 

As  uncertainty  increases,  resources  required  could  increase,  if  those 
resources  would  be  used  to  decrease  the  uncertainty  or,  in  a  case  that  involves  two 
or  more  uses  for  certain  resources,  the  uncertainty  is  enough  so  that  the 
decisionmaker  desires  to  use  resources  for  all  potential  paths,  in  order  to  "cover 
all  bets."  An  increase  in  resources  required  would  not  tend  to  drive  an  increase  in 
uncertainty,  however. 

xx.  Uncertainty-Information  Required 

As  uncertainty  increases,  information  required  could  also  increase,  because 
the  decisionmaker  would  want  more  information  in  order  to  reduce  his 
uncertainty.  Changes  in  information  required,  though,  should  not  cause  changes  in 
uncertainty. 

xxi.  Uncertainty-Task  Formalization 

Increases  in  uncertainty  could  also  elicit  increases  in  task  formalization, 
since  the  uncertainty  can  involve  the  structure  and  paths  taken  to  complete  the 
task.  This  is  not  necessarily  so,  however;  a  task  can  still  be  highly  formalized  and 
well  structured  if  some  or  many  of  the  states,  inputs,  outcomes,  or  environments 
are  not  well  known.  Changes  in  task  formalization  should  not  drive  changes  in 
uncertainty. 
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xxii.  Time  Pressure-Complexity 

Changes  in  time  pressure  can  cause  changes  in  complexity.  If  the  time 
pressure  decreases,  the  number  of  attributes  or  paths  that  can  be  considered  can 
increase,  because  of  the  additional  time  the  decisionmaker  has  to  consider  them. 
Also,  uncertain  or  probabilistic  linkages  can  decrease  if  time  pressure  decreases, 
because  the  decisionmaker  has  additional  time  to  reduce  his  uncertainty. 
Conversely,  changes  in  complexity  can  cause  changes  in  time  pressure.  If 
complexity  decreases,  the  amount  of  time  that  the  decisionmaker  must  devote  to 
sorting  out  the  situation  also  decreases,  and,  if  the  amount  of  time  available 
remains  constant,  time  pressure  will  decrease. 

xxiii.  Time  Pressure-Coordination  Requirements 

Changes  in  time  pressure  can  affect  coordination  requirements.  If  the  time 
pressure  increases,  coordination  between  two  or  more  entities  can  become  more 
difficult,  or  even  impossible,  because  the  time  available  to  communicate  and 
synthesize  is  lessened.  Conversely,  changes  in  coordination  requirements  can 
cause  changes  in  time  pressure.  If  coordination  requirements  are  lessened,  the 
amount  of  activities  that  must  be  performed  is  generally  lessened,  because  some 
of  those  activities  are  coordination-related,  such  as  the  actors  communicating  with 
one  another.  Lessening  the  number  of  activities  while  holding  the  time  available 
constant  reduces  time  pressure. 

xxiv.  Time  Pressure-Magnitude 

Since  time  pressure  and  magnitude  are  directly  related  (time  pressure  is 
magnitude  divided  by  time  available),  changes  in  one  will  cause  changes  in  the 
other,  unless  the  time  available  is  modified  accordingly. 

xxv.  Time  Pressure-Resources  Required 

Changing  time  pressure  would  tend  to  have  an  inverse  effect  on  resources 
required.  If  time  pressure  was  increased,  the  resources  required  would  tend  to  go 
down,  because  the  actors  would  not  have  time  to  use  all  the  resources  that  are 
available  to  them.  Changes  in  resources  required  would  tend  to  have  a  direct 
effect  on  time  pressure  —  if  resources  required  was  increased,  then  time  pressure 
would  increase,  because  of  the  additional  activities  that  would  probably  be 
required  to  put  those  resources  to  use,  as  long  as  time  available  is  held  constant. 

xxvi.  Time  Pressure-Information  Required 

This  interaction  should  be  the  same  as  the  time  pressure-resources  required 
interaction. 

xxvii.  Time  Pressure-Task  Formalization 

As  time  pressure  is  increased,  task  formalization  would  tend  to  increase,  in 
those  instances  where  there  is  a  more  structured  way  to  perform  a  task  that  may 
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not  achieve  the  goals  of  the  decisionmaker  as  well  as  a  less  structured  method 
will,  but  the  more  structured  method  would  tend  to  take  more  time.  As  task 
formalization  is  increased,  time  pressure  would  tend  to  decrease,  because  more 
formalized  tasks  would  tend  to  take  less  time  because  of  the  well-defined  nature 
of  the  activities  involved. 

xxviii.  Complexity-Coordination  Requirements 

Complexity  and  coordination  requirements  can  affect  each  other  in  many 
subtle  ways.  For  instance,  if  the  number  of  possible  paths  is  increased, 
coordination  requirements  could  be  increased,  because  of  a  possible  requirement 
to  coordinate  with  other  team  members  in  order  to  explore  the  paths.  Or, 
increasing  a  shared  resources  requirement  could  increase  the  number  of  possible 
paths  that  could  be  taken.  Changes  to  either  of  these  dimensions  must  be 
scrutinized  carefully  to  ensure  any  effect  on  the  other  has  been  accounted  for. 

xxix.  Complexity-Magnitude 

Increasing  complexity  can  increase  the  magnitude  of  a  task.  If,  for 
instance,  additional  activities  must  be  performed  in  order  to  resolve  a  complex 
issue,  then  magnitude  will  increase.  Additionally,  if  the  magnitude  of  a  task 
changes,  and  the  added  or  decreased  activities  affect  the  number  of  attributes, 
paths,  outcomes,  interdependence,  cues,  or  linkages  present,  then  the  complexity 
could  increase  or  decrease  as  well. 

xxx.  Complexity-Resources  Required 

Increasing  complexity  of  a  task  might  require  a  different  system  or  more 
personnel  to  aid  in  problem-solving  than  a  more  simple  task  would,  thus 
increasing  resources  required.  If  resources  required  to  complete  a  task  were 
decreased,  then  complexity  could  decrease  also,  because  the  decrease  in  resources 
required  could  result  in  fewer  attributes  or  paths  that  must  be  considered  by  the 
decisionmaker. 

xxxi.  Complexity-Information  Required 

Increasing  the  complexity  of  a  task  could  increase  information  required, 
because  the  decisionmaker  might  want  more  information  in  order  to  help  choose 
the  right  path,  or  decrease  uncertainty  of  linkages  between  paths  and  outcomes. 
Increasing  the  information  required  could  also  increase  task  complexity,  because 
the  additional  information  required  could  be  an  additional  attribute  that  the 
decisionmaker  must  consider. 

xxxii.  Complexity-Task  Formalization 

Increasing  complexity  can  decrease  task  formalization.  As  the  number  of 
attributes,  paths,  and  desired  outcomes  grows,  the  chore  of  formalizing  a  task  can 
become  more  difficult,  such  that  many  extremely  complex  tasks  are  not 
formalized  at  all,  because  of  the  number  of  characteristics  that  must  be 
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considered.  Increasing  task  formalization  may  or  may  not  increase  complexity. 
Increasing  formalization  and  adding  a  structured  way  of  looking  to  the 
decisionmaking  process  could  have  the  effect  of  decreasing  complexity,  or  at  least 
making  the  complexity  more  easily  manageable. 

xxxiii.  Coordination  Requirements-Magnitude 

Increasing  coordination  requirements  could  increase  the  magnitude  of  a 
task,  because  greater  coordination  requirements  could  result  in  additional 
activities  that  must  be  performed  in  order  to  coordinate  actions.  Changes  in  task 
magnitude,  however,  should  have  little  or  no  effect  on  coordination  requirements, 
unless  the  activities  that  were  added  or  deleted  specifically  involve  use  of  shared 
resources,  a  producer/consumer  relationship,  a  simultaneity  constraint,  or  the  task 
must  be  decomposed  into  subtasks  by  the  decision  makers. 

xxxiv.  Coordination  Requirements-Resources  Required 

Changes  to  the  coordination  requirements  should  not  affect  resources 
required  to  perform  a  task.  Increases  in  resources  required,  though,  could  cause 
coordination  requirements  to  increase,  because  the  additional  resources  required 
could  cause  a  necessity  to  share  available  resources  where  one  did  not  exist 
before,  unless  the  resources  available  were  also  increased. 

xxxv.  Coordination  Requirements-Information  Required 

Changes  to  coordination  requirements  should  not  affect  information 
required.  Increases  in  information  required  could  lead  to  increases  in  coordination 
requirements,  because  the  decision  makers  might  need  to  coordinate  actions  in 
order  to  obtain  the  additional  information. 

xxxvi.  Magnitude-Resources  Required 

Changes  in  the  magnitude  of  a  task  should  not  affect  resources  required  to 
complete  a  task,  unless  the  added  activities  require  more  resources  to  perform 
them.  Changes  in  resources  required,  however,  could  change  the  magnitude  of  a 
task,  if  the  additional  resources  needed  additional  activities  to  be  performed  in 
order  to  put  the  new  resources  to  use. 

xxxvii.  Magnitude-Information  Required 

Changes  in  the  magnitude  of  a  task  should  not  affect  information  required 
to  complete  a  task,  unless  the  added  activities  require  more  information  in  order  to 
perform  them.  Changes  in  the  information  required,  however,  could  change  the 
magnitude  of  a  task,  if  the  actors  had  to  perform  additional  activities  in  order  to 
obtain  the  added  information. 


xxxviii.  Resources  Required-Information  Required 

Changes  in  resources  required  to  complete  a  task  could  cause  changes  in 
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information  required,  if  the  additional  resources  needed  additional  information  in 
order  to  put  the  resources  to  use.  Conversely,  changes  in  information  required  to 
complete  a  task  could  result  in  changes  in  resources  required,  if  the  new 
information  requirement  needed  additional  resources  in  order  to  obtain  the 
'information.  [Berigan,  1996) 

E.         SUMMARY 

This  chapter  enumerated  the  dimensions  of  task  structure,  defined  them,  and 
demonstrated  a  method  of  grading  the  dimensions.  These  dimensions  will  be  used  to  vary 
the  overall  complexity  of  the  tasks/missions  in  the  experiment  as  we  develop  the 
"triggers"  or  "vignettes"  which  will  be  used  to  stimulate  adaption  in  the  test 
organizations.  Michael  Berigan's  review  of  the  pertinent  literature  surveyed  the  possible 
sources  of  information  and  various  opinions  on  dimensions  of  task  structure.  A  set  of  task 
dimensions  appropriate  for  the  purposes  of  the  A2C2  project  was  developed  and  defined 
and  a  comprehensive  breakdown  of  these  dimensions  was  provided.  Exceptions  to 
orthogonality  of  the  dimensions  were  identified  to  aid  in  compensating  for  any  effect 
which  changes  to  one  dimension  might  have  on  other  related  dimensions. 
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III.  TASK  STRUCTURE  DIAGRAM  AND  TASK  DESIGN  PROCESS 

This  chapter  focuses  on  the  development  of  a  task  structure  diagram  concept. 
Definitions  necessary  to  discuss  decomposition  of  tasks  into  component  subtasks  and 
actions  are  given  and  the  task  structure  diagram  is  described.  The  specific  features  and 
capabilities  of  the  diagram  are  discussed  followed  by  a  description  of  how  the 
dimensions  of  task  structure  developed  in  the  previous  chapter  relate  to  the  diagram. 
Finally,  the  concepts  of  Chapter  II  and  this  chapter  are  synthesized  into  a  task  design 
process  that  can  be  used  to  develop  military  operational  scenarios,  or  more  general  tasks, 
in  an  experimental  context. 

A.  INTRODUCTION 

Determining  the  dimensions  of  task  structure  is  an  important  area  of  experimental 
design  for  the  A2C2  project.  It  establishes  the  groundwork  for  designing  and 
differentiating  tasks  based  on  dimensions.  Once  dimensions  are  defined,  a  method  is 
developed  to  assist  the  experimenter  in  visually  describing  the  task  structure,  flow,  and  as 
many  of  the  dimensions  defined  in  Chapter  II  as  necessary  for  expository  purposes.  A 
visual  method  makes  the  task  design  and  differentiation  less  complex. 

B.  DEFINITIONS 

The  development  of  a  task  structure  diagram  involves  decomposing  tasks  to  the 
lower  level  activities  from  which  they  are  constructed.  In  order  to  discuss  the  subject,  we 
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must  have  common  definitions  for  the  various  activities  and  define  what  is  meant  by  task 
structure  and  task  structure  diagram.  For  the  purposes  of  continuity  in  the  A2C2  Project,  I 
will  use  the  same  definitions  for  these  terms  as  Michael  Berigan's  work  for  experiment  1. 


1.  Activity 

An  activity  is  any  act  that  must  be  performed,  at  a  high  or  low  level  of  task 
decomposition.  For  our  purposes,  it  is  a  generic  term  encompassing  tasks, 
subtasks,  and  actions. 

2.  Task 

A  task  is  the  macro  level  activity.  It  describes  the  overall  activity  that  is 
being  performed  by  the  actors.  Since  it  is  really  impossible  to  define  beforehand 
the  magnitude  of  the  task,  for  our  purposes,  it  is  defined  as  the  level  that  is  the 
primary  focus  of  the  study. 

3.  Subtask 

A  subtask  is  a  next-lower  level  component  of  a  task.  The  nodes  on  a  task 
structure  diagram  are  subtasks.  There  can  be  more  than  one  level  of  subtasks;  if 
there  are  multiple  layers,  the  highest  layer  of  subtasks  is  subtask  level  1. 

4.  Action 

Actions  are  activities  that  are  in  their  most  elemental  state  for  the  uses  of 
the  study.  Actions  are  either  not  further  decomposable,  or  further  decomposition 
would  be  impractical  or  would  serve  no  purpose. 

5.  Task  Structure 

Task  structure  is  defined  as  the  flow  of  subtasks  within  a  task  in  the  time 
domain. 

6.  Task  Structure  Diagram 

A  task  structure  diagram  is  a  visual  model  of  a  task  which  describes  the 
task  structure,  and  as  many  characteristics  of  a  task  as  practical.  The  task  structure 
diagram  is  designed  to  simplify  understanding  of  the  task  and  manipulation  of 
potential  variables.  (Berigan,  1996) 
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C.         TASK  STRUCTURE  DIAGRAM 

Task  structure  diagrams  based  on  Hatley  and  Pirbhai's  data  flow  diagram  (DFD) 
concept  (Hatley  and  Pirbhai,  1988)  will  be  used  to  provide  a  visual  representation  to 
experiment  designers  of  the  flow  of  subtasks  and  actions  within  a  task.  Dimensions  of 
task  structure  are  represented  directly  or  inferred  from  this  task  structure  diagram.  By 
visualizing  the  structure  of  a  task,  experimenters  are  able  to  determine  if  a  task 
accomplishes  the  objectives  that  have  been  set.  Task  structure  diagrams  provide  a 
straightforward,  pictorial  method  for  comparing  tasks  and  for  describing  a  task  outside 
the  scenario  design  process.  Experiment  designers  can  also  delineate  task  structures  they 
are  interested  in  testing,  and  the  scenario  developed  to  fit  that  structure.  This  "object 
oriented"  view  of  task  structure  design  allows  designers  to  treat  activities  and  nodes  as 
modules,  rearranging  as  necessary  to  achieve  experiment  scenario  goals  and  objectives. 

Highly  structured  or  formalized  tasks  are  easily  described  using  this  method,  but 
some  tasks  are  composed  of  numerous  alternative  subtasks.  The  alternative  path  options 
grow  exponentially,  until  the  labor  involved  in  developing  the  diagram  outweighs  the 
benefits  gained  from  its  use.  Figure  1  is  an  example  of  a  task  structure  diagram.  A 
description  of  the  diagram  and  its  building  blocks  is  provided.  2. 

1.  Flow  Description 

Each  diagram  represents  one  task  or  subtask.  The  individual  subtasks  and 
actions  within  each  task  or  subtask  are  the  nodes,  represented  by  the  circles  or 
rectangles.  The  task  flows  in  time  from  the  "start"  box  to  the  completion  of  the 
final  subtask.  Thus  there  may  be  many  "levels"  of  diagrams  for  each  task. 
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Subtask  1 


Sub  task  6 


Taskl 


'.  Subtask  5 


\  Subtask  7 


OR  operator 


Code  for  diagram 
DM  1  task  Bold  print 

DM  2  task  Italic  print 

Common  task        Regular  Print 
Competitive  task    Underlined  print 
Static  task  Rectangle 

Dynamic  task         Oval 
Decomposable  task  Dotted  boundary 
Parallel  or  Bold  connection 

Simultaneous  Tasks 


U 


AND  operator      \^J 

Hard  Prereq.        

Soft  Prereq. 


Figure  1:  Task/Subtask  Level  Task  Structure  Diagram  (from  Berigan,  1996) 

32 


2.  Actors 

Actor  refers  to  the  Decision  Maker  who  performs  each  subtask  in  Figure  1 
and  is  represented  by  the  style  of  type  used  for  the  name  of  the  subtask.  For 
example,  if  the  subtask  is  given  in  bold  type,  then  DM  1  is  the  task  performer,  if 
the  subtask  is  given  in  italic  type,  then  DM  2  is  the  task  performer.  If  the  subtask 
is  in  normal  type,  then  both  Decision  Makers  are  involved  in  the  subtask.  If  there 
are  more  than  two  actors  are  involved  in  a  task,  then  a  identification  schema 
would  have  to  be  used.  In  Figure  1 ,  decisions  for  subtasks  2  and  5  are  made  by 
DM  2,  decisions  for  subtasks  3,4,7,  and  9  are  made  by  DM  1.  All  the  other 
subtasks  are  common  tasks  and  may  be  performed  by  several  DM's.  (  This  section 
of  text  from  Berigan  1996  was  modified  to  correct  for  figure  number  and  changes 
to  the  figure.) 

3.  Decomposability 

Decomposability  implies  that  a  task  or  subtask  can  be  divided  further  into 
lower  level  subtasks  or  actions  (Simon,  1981,  pp.  196-210).  Decomposability  will 
be  represented  by  the  border  of  the  figure  representing  each  activity.  A  solid 
border  represents  an  item  that  is  not  decomposable  —  the  task,  subtask,  or  action 
represented  is  at  its  most  basic  level.  A  dotted  border  represents  an  activity  that 
can  be  broken  down  into  lower  level  activities. 

4.  Simultaneity  (same  as  Parallel) 

Simultaneity  is  the  requirement  that  two  or  more  activities  are  to  be 
performed  concurrently  or  must  be  synchronized.  Simultaneity  is  a  dependency 
between  actions  that  is  included  in  the  coordination  requirements.  Simultaneity  is 
represented  by  a  bold  line  joining  the  activities  which  have  this  dependency 
relationship. 

5.  AND  Operator 

The  AND  operator  implies  that  all  the  activities  feeding  into  it  must  be 
completed  before  the  activities  following  it  can  be  performed.  The  AND  operator 
is  represented  in  the  diagram  by  a  half-moon  shape. 

6.  OR  Operator 

The  OR  operator  indicates  the  requirement  that  one  of  the  activities 
feeding  into  it  must  be  completed  before  the  activities  following  it  can  be 
performed.  The  OR  operator  is  represented  in  the  diagram  by  a  crescent  shape. 


7.         Competition 
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Activities  are  competitive  if  two  or  more  actors  require  the  same  resource 
simultaneously  to  accomplish  them.  Competition  is  represented  by  underlining  the 
title  of  the  Competition  is  another  of  the  coordination  requirements  dependencies, 
shared  resources. 

8.  Dynamicity 

Dynamicity  is  a  measure  of  the  change  to  one  or  more  of  the  dimensions  of 
a  task  over  time.  The  shape  of  the  figure  representing  the  activity  indicates 
Dynamicity;  rectangles  are  non-dynamic,  or  static  subtasks,  and  ovals  are  dynamic 
subtasks. 

9.  Prerequisites  —  Hard  and  Soft 

Prerequisites  are  the  activities  that  are  performed  prior  to  another  activity. 
A  prerequisite  is  considered  a  hard  prerequisite  if  it  must  be  performed  prior  to 
performing  a  given  activity.  A  hard  prerequisite  is  represented  in  the  diagram  by  a 
solid  arrow  (line)  connecting  activities.  A  soft  prerequisite  is  an  activity  which 
should  be  performed  prior  to  a  given  activity  for  optimal  results,  but  the  following 
activity  can  be  accomplished  without  the  prerequisite  being  performed  first.  A  soft 
prerequisite  is  denoted  by  a  dashed  arrow  (line)  connecting  activities. 

10.  Decomposing  Tasks  into  Subtasks  and  Actions 

Figure  1  represents  a  task  broken  into  subtasks.  Some  of  the  subtasks  are 
in  their  elemental  state  —  they  are  at  the  lowest  activity  or  action  level.  Others  can 
be  decomposed  at  least  one  more  level,  some  can  be  decomposed  several  more 
levels.  Figure  2  represents  a  subtask  decomposed  into  its  elemental  component 
actions. 

11.  Elemental  State  Task  Structure  Diagrams 

The  elemental  state  task  structure  diagram  follows  the  same  format  as 
previously  discussed  for  the  task  structure  diagram.  The  elemental  state  task 
structure  diagram  contains  a  breakdown  of  the  dimensions  (see  Chapter  II)  of  task 
structure  that  apply  to  each  action  not  previously  shown  in  the  task  structure 
diagram  (only  those  that  are  graded  as  other  than  "Low"  or  "None"),  and  the 
resources  and  information  required  to  complete  the  action.  (Berigan,  1996) 
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Code  for  diagram 
DM  1  task 
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Common  task 
Competitive  task 
Static  task 
Dynamic  task 
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Italic  print 
Regular  Print 
Underlined  print 
Rectangle 
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Decomposable  task  Dotted  boundary 
Parallel  or  Bold  connection 

Simultaneous  Tasks 
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Figure  2:  Subtask  Decomposed  To  Its  Most  Basic  Components 
(Berigan  1996,  p  41) 
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D.         OPERATIONALIZING  DIMENSIONS  OF  TASK  STRUCTURE  IN  A 
TASK  STRUCTURE  DIAGRAM 

For  the  task  structure  diagram  and  the  dimensions  of  task  structure  to  be  of  any 
use  to  us,  we  must  be  able  to  link  the  two  issues.  Each  dimension  of  task  structure  must 
be  delineated  in  the  task  structure  diagram.  Delineation  of  some  of  the  dimensions  in  a 
task  or  subtask  is  straightforward,  while  others  are  more  subtle.  The  manifestation  of 
each  of  the  nine  dimensions  of  task  structure  in  the  task  structure  diagram  is  detailed  in 
this  section. 


1.  Uncertainty,  Time  Pressure,  Complexity 

Uncertainty,  time  pressure,  and  complexity  are  shown  in  the  task  structure 
diagram  by  assigning  them  a  value  in  the  diagram  that  shows  a  task  in  its  most 
elemental  state,  (See  Figure  2).  The  score  for  a  subtask  in  each  of  these 
dimensions  is  the  mean  of  the  grades  (scores)  of  all  the  actions  that  comprise  the 
subtask;  the  score  for  a  task  in  each  dimension  is  the  mean  of  the  grades  (scores) 
of  all  the  subtasks  that  comprise  the  task.  (Figure  number  modified  to  correspond 
to  proper  figure) 

2.  Coordination  Requirements 

Coordination  requirements  are  shown  several  ways  in  the  task  structure 
diagram.  If  the  grade  for  each  dependency  is  High  or  Medium,  it  will  be  listed 
with  the  action  in  which  it  is  associated  on  the  elemental  state  task  structure 
diagram.  The  different  types  of  dependencies  are  represented  in  the  diagram  in  the 
following  ways: 

a.  Shared  Resources 

Competitive  subtasks  that  are  underlined  implies  competition  over 
shared  resources  at  a  scoring  level  of  Medium  or  High. 

b.  Producer/Consumer  Relationships 

Hard  prerequisite  indicators  (a  solid  arrow  connecting  activities)  in 
a  task  structure  diagram  imply  that  a  producer/consumer  dependency  exists,  the 
follow-on  activity  cannot  be  performed  until  the  first  is  complete. 
Producer/consumer  dependency  is  graded  as  Medium  or  High.  A  high  score 
indicates  a  task  or  subtask  that  cannot  be  accomplished  out  of  sequence,  a  medium 
score  indicates  the  task  or  subtask  can  be  completed  out  of  sequence  but 
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performance  score  will  be  significantly  degraded. 

c.  Simultaneity  Constraints 

Simultaneity  indicators  (a  solid  bar  connecting  the  activities)  in  the 
task  structure  diagram  imply  that  simultaneity  constraints  are  Medium  or  High. 
High  indicates  tasks  or  subtasks  that  must  occur  at  the  same  time,  medium 
indicates  tasks  that  should  be  performed  at  the  same  time  for  maximum 
performance  score. 

d.  Task/Subtask 

The  task  structure  diagram  shows  the  breakdown  of  a  task  into  its 
component  subtasks  and  actions,  and  also  depicts  which  actor  or  DM  is  assigned 
to  complete  each  task  or  subtask.  This  is  not  the  same  as  the  allocation  of  tasks  or 
subtasks  by  the  DM's  in  the  actual  runs.  This  is  the  task/subtask  dependency 
which  not  manifested  in  the  diagram  itself,  except  as  the  grade  given  in  the 
elemental  state  task  structure  diagram  .(Inserted  for  clarification  of  Berigan's 
work.  In  order  for  UCONN  modelers  to  input  the  data  into  the  model,  they  needed 
to  have  tasks  and  subtasks  assigned  to  DMs  or  nodes,  this  was  provided  by  the 
task  structure  diagram.  This  was  not  necessarily  the  actual  division  of  labor  that 
resulted  in  the  experimental  runs.) 

3.  Magnitude 

The  magnitude  of  a  task  is  determined  by  counting  the  total  number  of 
actions  in  the  task  structure  diagrams,  starting  at  the  highest  level  and  breaking  the 
task  down  to  its  elemental  states. 

4.  Resources  and  Information  Required 

Resources  and  required  information  are  listed  in  the  elemental  state  task 
structure  diagram.  Counting  the  total  resources  and  pieces  of  information  required 
for  each  action  within  a  task  gives  the  total  resources  and  information  required  for 
the  task. 

5.  Task  Formalization 

Indicators  of  task  formalization  in  the  diagram  are  the  ratio  of  soft  to  hard 
prerequisites  (more  soft  prerequisites  would  imply  less  formalization),  and  the 
number  of  "or"  operators  (fewer  "OR"  operators  implies  more  formalization).  A 
task  that  can  be  readily  displayed  using  the  task  decomposition  method  would 
have  at  least  a  medium  level  of  formalization.  Attempts  to  decompose  tasks  with 
low  formalization  would  numerous  alternative  paths  that  decisions  makers  could 
take  with  no  degradation  in  performance  scores.  (Berigan,  1996) 
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E.    DESIGNING  THE  TASK 

The  scenario  development  and  task  design  problem  identified  in  Chapter  I  can 
now  be  approached  in  a  straightforward  manner.  The  process  consists  of  four  steps: 

1 .  Determining  the  dimension  of  task  structure  of  interest. 

2.  Determining  the  desired  task  structure. 

3.  Developing  the  scenario. 

4.  Grading  scenarios  by  dimensions. 

The  second  and  third  steps  are  interchangeable.  This  process  will  often  be 
iterative,  with  at  least  the  second,  third,  and  fourth  steps  repeated  more  than  one  time. 

1.  Dimension  of  Interest 

The  goals  of  the  experiment  determine  the  dimension(s)  of  task  structure  (if  any) 

that  are  of  interest.  If  a  task  structure  dimension  is  of  interest,  then  task  structure  will 
usually  be  an  independent  variable.  A  researcher  must  determine  what  his  dimension(s)  of 
interest  will  be.  He  should  then  determine  the  number  of  levels  needed  based  on  the 
constraints  of  his  experiment,  and  at  least  an  approximation  of  the  values  the  levels  will 
take  on.  The  researcher  should  also  determine  any  of  the  other  task  structure  dimensions 
he  desires  to  hold  constant,  if  important  to  his  investigation. 

2.  Desired  Task  Structure 

Several  options  are  available  for  sequencing  the  development  of  the  task  structure 

diagram.  If  a  specific  structure  or  characteristic  (such  as  simultaneity)  is  desired  then  a 
preliminary  task  structure  diagram  should  be  developed  after  the  dimension  of  interest 
has  been  determined,  filling  in  detail  as  the  scenario  is  written.  If  no  specific  task 
structure  requirement  for  the  experiment  exists,  then  the  task  structure  diagram  should  be 
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developed  concurrently  with  the  scenario,  using  it  as  a  briefing,  explanation,  editing,  and 
grading  tool. 

3.  Scenario  Development 

The  scenario  development  should  take  dimension(s)  of  interest  and  desired  task 

structure  into  consideration  as  well  as  ensuring  the  experiment  fits  within  the  other 
constraints  and  limitations,  such  as  project  context,  other  independent  variables,  subject 
pool,  time  and  resources  available,  et  cetera. 

4.  Grading  Dimensions  of  Task  Structure  in  Scenarios 

In  order  to  determine  whether  dimensions  differ  or  are  held  constant,  the 

scenario(s)  should  be  graded  based  on  the  levels  of  dimensions  of  task  structure  as 
described  in  Chapter  II. 

F.         SUMMARY 

In  this  chapter  a  visual  representation  of  a  task's  structure  was  developed  using 
the  data  flow  diagram  (DFD)  concept  of  Hatley  and  Pirbhai.  Definitions  necessary  to 
discuss  task  decomposition  were  provided  and  the  task  structure  diagram  and  its  features 
described.  The  task  structure  diagram  provides  the  dimensions  of  task  structure,  shows 
the  flow  of  subtasks  and  actions  in  the  time  domain,  and  depicts  optional  paths,  hard  and 
soft  prerequisites,  and  decomposability.  A  methodology  was  developed  for  designing  a 
military  operation  scenario  based  on  task  structure. 
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IV.  SCENARIO  AND  ORGANIZATION  ARCHITECTURE  FOR 
THE  SECOND  A2C2  EXPERIMENT 


This  chapter  focuses  on  the  development  and  modification  of  the  scenario  and 
organizational  structures  from  the  first  NPS  experiment  for  use  in  the  second  A2C2  NPS 
experiment.  The  second  experiment  evaluates  two  different  organizational  structures,  one 
model-based,  developed  at  UCONN,  and  the  other  developed  at  NPS  using  current 
military  doctrine  as  the  basis  for  its  design.  The  tools  developed  in  the  preceding  chapters 
are  used  to  design  the  scenario  tasks,  develop  an  organizational  structure,  and  provide 
inputs  to  UCONN  modelers  for  generating  their  model-based,  optimized  organizational 
structure.  A  description  of  the  resulting  NPS  and  model-based  organizational  structures 
and  an  overview  of  the  conduct  of  the  experiment  are  also  presented. 


A.         INTRODUCTION 

The  background  information  provided  in  Chapters  II  and  ED  showed  how  a 

paradigm  was  developed  for  visually  representing  task  structure,  determining  levels  of 
dimensions  of  task  structure,  and  stipulating  a  process  for  designing  a  task  based  on  the 
task  structure  dimension  of  interest  and  desired  task  structure.  The  main  focus  of  this 
thesis,  the  second  NPS  experiment  of  the  A2C2  program,  used  this  paradigm  to  design 
the  experimental  tasks  and  supporting  scenario.  An  organization  plans  and  prepares  to 
accomplish  a  mission  or  task  by  the  assigning  its  resources  to  appropriate  DMs 
(commanders)  in  an  organizational  structure  designed  to  accomplish  that  mission. 
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Investigating  organization  adaption  is  the  primary  goal  of  the  A2C2  project.  A 
basic  premise  of  the  A2C2  program  is  that  an  organization's  structure  should  be 
"designed"  based  on  resources  available  and  tasks  required  to  complete  the  assigned 
mission  and  that  "significant"  changes  to  the  mission/task  structure  or  a  change  in  the 
organization's  assets  should  induce  changes  in  the  organization's  structure.  The  A2C2 
research  team  elected  to  use  an  analytic-empirical  approach  to  conduct  model-driven 
experiments  with  human  organizations  in  the  context  of  a  joint  military  scenario  to 
examine  these  and  other  hypotheses  in  a  controlled  laboratory  environment. 

The  NPS  experiments  thus  far  have  utilized  the  Distributed  Dynamic 
Decisionmaking  (DDD-HI)  software  (Kleinman,  Young  and  Higgins,  1996),  which  was 
developed  at  UCONN  and  installed  at  NPS  and  other  sites  to  support  studies  in 
organizational  theory.  The  design  of  the  second  experiment  is  an  extension  of  experiment 
one  conducted  at  NPS  in  early  1996  (Kemple,  Kleinman  and  Berigan,  1996). 

The  context  for  experiment  two  involved  a  Joint  Task  Force  (JTF)  in  a  six-node 
organizational  hierarchy  conducting  a  multi-faceted  amphibious  scenario  that  included 
maritime,  ground,  and  air  activities.    The  challenges  of  determining  the  dimensions  of 
task  structure  to  be  varied,  the  task  and  organizational  structures,  and  the  development  of 
a  scenario  for  the  second  experiment  will  be  discussed  in  this  chapter. 

Several  issues  needed  to  be  resolved  while  designing  the  experiment: 

•  How  to  measure  an  organization's  performance  as  they  perform  the  same 

tasks,  but  with  resources  assigned  to  different  organizational  nodes  that  are 
also  structurally  different.  A  variety  of  task  structures  were  required  to  see 
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if  interactions  between  task  and  organizational  structures  exists. 
•  How  can  internal  and  external  stimuli  (called  triggers)  that  are  essentially 

equivalent  in  terms  of  the  task  load  to  resource  ratio,  be  injected  into  the 
scenario  to  induce  adaptation  in  the  organizations.  An  internal  stimulus  is 
a  change  to  resources  or  capabilities  of  the  organization.  An  external 
stimulus  is  a  change  in  the  environment  or  mission. 
Following  is  a  description  of  the  development  of  the  scenario,  organization 
structures,  and  the  design  and  conduct  of  the  second  experiment. 

B.         DETERMINATION  OF  THE  DIMENSIONS  OF  INTEREST 

Coordination  requirements  between  DMs  to  share  limited  resources  to  complete 
complex  tasks  is  the  task  structure  dimension  of  interest  for  the  second  experiment.  A 
complex  task  is  one  that  requires  more  than  one  resource  type  to  be  successfully 
completed. 

The  coordinated  resources  dependency  varied  over  level  one,  internal  coordination 
of  resources  —  the  DM  responsible  for  completing  a  task  owns  all  the  assets  necessary  to 
accomplish  it;  and  level  two,  external  coordination  of  resources  —  the  DM  responsible  for 
completing  a  task  must  work  with  one  or  more  DMs  to  obtain  the  assets  necessary  to 
accomplish  the  task.  Although  it  was  desired  to  define  dimensions  of  task  structure  that 
were  independent  from  the  organizational  structures,  whether  the  coordination  for  a 
particular  task  is  internal  or  external  is  a  function  of  the  design  of  the  organizational 
structure.  (See  Chapter  II)  The  coordinated  resources  dependency  level  was  a  between 
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teams  factor,  with  the  TA  teams  experiencing  a  higher  level  than  the  NTA  teams.  This  is 
because  the  NTA  structure  was  specifically  designed  to  minimize  this  dimension  among 
other  things.  It  was  desired  that  all  other  dimensions  of  task  structure  be  the  same  for  both 
architectures  until  the  triggers  were  introduced  (discussed  below). 

The  efficiency  and  performance  of  the  organizational  structures  was  of  interest  in 
the  second  NPS  experiment.  The  organizational  structures  were:  model-based, 
operationally-based,  and  dynamically  selected  by  the  subjects  during  the  planning 
sessions.  (The  dynamically  selected  architectures  will  be  discussed  in  Chapter  V.  The 
players  did  not  function  in  the  dynamically  selected  architectures  as  part  of  the  second 
NPS  experiment,  but  they  are  being  evaluated  with  simulations  by  other  research  teams.) 
This  interest  results  in  the  following  research  questions: 

1.  Does  the  performance  of  the  model-based  organization  match  the  model's 
predictions  of  performance? 

2.  In  the  face  of  an  internal  "trigger",  do  teams  adapt  by  changing  organizational 
architectures? 

3.  In  the  face  of  an  external  "trigger",  do  teams  adapt  by  changing  organizational 
architectures? 

4.  Do  organizations  adapt  their  organizational  structures  based  on  changes  in 
mission  task  and  resources  available? 

5.  Why  and  how  do  organizations  adapt? 

6.  Are  some  organizational  structures  able  to  accommodate  changes  to  mission  or 
resources  better  than  others  (without  a  drop  in  performance)?  Are  some  organizations 
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more  robust  than  others?  If  so,  why? 

7.  Can  the  model-based  organizational  structures  developed  by  the  modelers  at 
UCONN,  based  on  task  structure  and  available  resources,  perform  as  well  or  better  than 
organizational  structures  developed  by  the  traditional  method  used  by  operational 
commanders  as  measured  by  performance,  resources  utilization,  mission  accomplishment, 
and  losses? 

These  questions  were  the  foundation  for  developing  the  hypotheses  that  were 
proposed  for  testing  in  the  second  NPS  experiment. 

C.         RESEARCH  ISSUES  AND  HYPOTHESES 

From  the  goals  and  objectives  of  the  A2C2  project  and  the  general  research 
questions  described  above,  the  A2C2  team  formulated  several  general  research  issues 
which  are  the  basis  for  the  hypotheses  of  all  the  A2C2  experiments.  These  are: 

1 .  Can  model-based  tools  predict  the  optimum  organizational  structure  to 
complete  a  mission  given  the  task  structure,  available  resources,  and  constraints? 

2.  Can  the  drivers  for  organizational  adaptation  be  identified? 

3.  Can  an  adaptation  to  other  organizational  structures  that  perform  better  be 
predicted  by  model-based  tools  after  task  structure  or  resource  changes  ? 

From  these  research  issues,  the  major  null  and  alternative  hypotheses  for  the 
second  NPS  experiment  were  developed: 

H0l:  There  is  no  interaction  between  task  structure  and  organization  structure, 
when  coordination  requirement  is  the  dimension  of  interest. 
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Hal:  There  is  interaction  between  task  structure  and  organization  structure,  when 
coordination  requirement  is  the  dimension  of  interest. 

Ho2:  Changes  in  levels  of  tasking  will  not  cause  organizations  to  adapt. 

Ha2:  Changes  in  levels  of  tasking  will  cause  organizations  to  adapt. 

Ho3:  Changes  in  levels  of  resources  will  not  cause  organizations  to  adapt. 

Ha3:  Changes  in  levels  of  resources  will  cause  organizations  to  adapt. 

These  hypotheses  are  based  on  the  assertion  that  an  organization  will  design  its 
resources  and  organizational  structure  to  accomplish  its  mission  within  acceptable  limits 
of  applicable  constraints  such  as  expected  mission  duration,  total  losses,  casualties,  and 
damage  (own,  enemy,  and  collateral),  and  other  costs.  The  resources  and  tasks  required  to 
achieve  a  mission  will  influence  the  structure  of  the  organization.  Based  on 
organizational  theory  (class  notes  from  MN  3105,  Organizational  Structures,  Fall  Quarter 
1 996)  the  organization  should  adapt  its  structure  when  mission  changes  affect  the  task 
structure  or  there  is  a  change  in  the  availability  of  resources.  This  is  most  likely 
dependent  on  the  degree  of  change  in  the  mission,  task  structure,  or  resources.  If  the 
mission  may  be  successfully  completed  by  the  existing  organizational  structure,  there  may 
be  no  adaptation.  The  motivation  to  change  is  based  on  the  tradeoff  between  improved 
performance  gained  and  the  costs  to  reorganize.  When  the  task  or  resource  changes 
become  large  enough  to  affect  the  probability  of  successfully  completing  the  mission,  in 
the  opinion  of  the  commander,  I  believe  this  will  induce  change  in  the  organizational 
structure.  This  will  be  investigated  in  experiment  three  at  NPS  in  November  1997. 
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D.         DESIRED  TASK  STRUCTURE 

The  mission,  characteristics,  task  structure,  and  types  of  resources  used  in  the 
first  NPS  experiment  that  were  compatible  with  the  goals  of  the  second  NPS  experiment 
were  reused  where  possible.  This  allowed  more  effort  to  be  devoted  to  the  organizational 
structure  issues.  Many  of  the  same  parameters  and  dimensions  designed  into  the  first 
experimental  scenario  were  of  interest  in  the  second  experiment.  A  higher  level  of 
workload  on  the  DMs  was  desired  as  was  a  more  balanced  workload  among  DMs,  so 
additional  background  tasks  were  added  to  the  scenario.  A  background  task  is  a  minor 
task  that  can  be  handled  by  one  asset  or  platform  without  assistance  from,  or  coordination 
with,  other  DMs.  The  purpose  behind  a  background  task  is  to  increase  the  workload  on 
DMs  and  cause  distractions,  resulting  in  increased  stress,  time  pressure,  and  ambiguity  on 
the  DMs. 

1.  Formalization  of  Scenario  Task  Structure 

To  test  our  hypotheses,  the  experiment  was  designed  to  measure  the  performance 
of  teams  attempting  to  perform  the  same  mission,  given  the  same  resources  and  task 
structure,  but  using  different  organizational  structures.  Therefore  a  high  degree  of 
formalization  in  the  design  of  the  experiment  was  used,  resulting  in  a  consistent  overall 
task  structure  form  and  replicable  events  that  occur  during  each  trial.  The  two  initial 
organizational  structures,  traditional,  and  nontraditional,  were  perturbed  by  the  systematic 
introduction  of  two  levels  of  two  factors,  resource  inventory  at  normal  and  reduced  levels 
and  task  load  at  normal  and  increased  levels.  Traditional  (TA)  is  the  name  given  to  the 
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organizational  structure  developed  by  the  NPS  researchers,  nontraditional  (NTA)  is  the 
name  given  to  the  model-based  organizational  structure  developed  by  the  modelers  at 
UCONN.  Replication  and  counterbalancing  were  used  to  control  for  other  factors  that 
might  confound  the  results. 

Based  on  the  hypotheses  for  this  experiment  and  the  selection  of  the  coordination 
requirement  dimension  of  task  structures,  "limited  capability"  resources  were  used  in 
order  to  require  coordination  between  platforms  and  possibly  DMs  to  successfully 
complete  the  assigned  mission.  A  military  force/platform  may  have  the  capability  to 
complete  more  than  one  task  or  perform  the  same  task  in  more  than  one  way.  For 
example,  a  DDG,  in  a  real  engagement,  might  fire  enough  rounds  from  a  5"  gun  to  ensure 
destruction  of  a  target  without  using  ground  troops  or  air  support.  In  the  experiment,  if  an 
asset  could  launch/conduct  more  than  one  attack  at  a  time  to  perform  a  given  task,  DMs 
would  be  able  to  avoid  the  coordination  requirements  by  assigning  multiple  attacks  on  a 
target  by  a  single  platform.  Since  the  coordination  events  were  the  focus  of  the 
experiment,  platforms  were  only  allowed  to  conduct  one  attack  on  a  single  target  at  a 
time.  An  additional  constraint  placed  on  the  attacks  requiring  coordination  was  that 
cooperating  DMs  only  had  a  ten  second  window  within  which  to  commit  their  assets  to 
the  simulated  attack,  otherwise  DDD  considered  them  as  separate  attacks. 

DDD  requires  certain  amounts  and  types  of  resource  mixes  to  successfully  engage 
a  target.  If  inappropriate  assets  are  used,  enemy  targets  escape  unscathed  and  DDD 
subtracts  team  performance  points.  If  inadequate  resources  are  used,  enemy  targets  are 
destroyed  but  the  team  loses  performance  points.  An  inappropriate  attack  is  one  that  has  a 

48 


zero  capability  value  summed  across  participating  resources  (platforms)  in  one  or  more  of 
the  vector  attributes  required  by  the  task.  An  inadequate  attack  was  one  that  had  a 
capability  value  summed  across  participating  resources  greater  than  zero  but  less  than  the 
task  attribute  vector  value.  See  Tables  2  and  3  for  examples  of  resource  and  task  attribute 
vectors,  they  are  discussed  in  detail  later  in  this  chapter.  As  an  example,  the  amphibious 
landing  on  blue  beach,  listed  as  B.  Beach  row  in  Table  3,  requires  ten  units  of  ground 
assault,  twelve  units  of  fire  support,  and  eight  units  of  armor.  An  appropriate  attack  (from 
Table  2)  could  consist  of  one  rifle  company  and  one  section  of  CAS,  the  totals  for  this 
combination  of  assets  would  be  two  units  of  air,  three  units  of  ASUW,  ten  units  of  ground 
assault,  twelve  units  of  fire  support,  ten  units  of  armor,  ten  units  of  hold,  and  two  units  of 
mine  land;  this  meets  or  exceeds  the  required  values  for  the  task,  other  combinations  of 
resources  to  successfully  complete  the  task  are  also  possible.  An  inappropriate  attack 
could  be  two  DDGs  and  a  Cobra  section.  The  totals  for  this  attack  would  be  23  units  of 
air,  24  units  of  ASUW,  two  units  of  ASW,  24  units  of  fire  support,  13  units  of  armor,  and 

I  unit  of  mine  land.  Since  the  task  requires  ten  units  of  ground  assault  and  the  assets 
attacking  have  zero  ground  assault  capability,  the  attack  is  inappropriate.  An  inadequate 
attack  could  consists  of  one  rifle  company  and  a  DDG.  The  totals  for  this  attack  would  be 

I I  units  of  air,  ten  units  of  ASUW,  one  unit  of  ASW,  ten  units  of  ground  assault,  1 1  units 
of  fire  support,  eight  units  of  armor,  and  ten  units  of  hold.  Since  the  task  requires  twelve 
units  of  fire  support,  the  attack  lacks  sufficient  combat  potential  in  that  one  category, 
even  though  there  is  adequate  combat  potential  in  all  other  categories. 
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Asset 

AER 

ASUW 

ASW 

GND 

ASLT 

FERE 
SUPP 

ARMOR 

HOLD 

MINE 
SEA 

MINE 
LAND 

MED 

DDG 

10 

10 

1 

0 

9 

6 

0 

0 

0 

0 

FFG 

1 

4 

10 

0 

4 

3 

0 

0 

0 

0 

CG 

10 

10 

1 

0 

9 

2 

0 

0 

0 

0 

CV 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

LSD 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

LHA 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

LPD 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Eng  Pit 

0 

0 

0 

2 

0 

0 

2 

0 

10 

0 

RFLECO 

1 

0 

0 

10 

2 

2 

10 

0 

1 

0 

StrDet 

5 

0 

0 

0 

0 

0 

0 

0 

0 

0 

COBRA 
SEC 

3 

4 

0 

0 

6 

10 

0 

0 

1 

0 

Cas  Sec 

1 

3 

0 

0 

10 

8 

0 

0 

1 

0 

Ftr  Sec 

6 

1 

0 

0 

1 

1 

0 

0 

0 

0 

Huey 

Med 

0 

0 

0 

0 

0 

0 

0 

0 

0 

10 

MCM 
HUEY 

0 

0 

0 

0 

0 

0 

0 

10 

0 

0 

RECON 
AKCFT 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

AAAV 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

MV-22 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Table  2:  Platform  Attribute  Vector  values 
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Task 

Name 

AIR 

ASUW 

ASW 

GND 
ASLT 

FIRE 
SUPP 

ARMOR 

HOLD 

MINE 
SEA 

MINE 
LAND 

Hill 

0 

0 

0 

10 

12 

8 

0 

0 

0 

R.  Beach 

0 

0 

0 

0 

12 

8 

0 

0 

0 

B.  Beach 

0 

0 

0 

10 

12 

8 

0 

0 

0 

Seaport 

0 

0 

0 

20 

10 

4 

0 

0 

0 

Airport 

0 

0 

0 

20 

10 

4 

0 

0 

0 

Artillery 

0 

0 

0 

0 

0 

6 

0 

0 

0 

FrgLanhr 

0 

0 

0 

0 

0 

6 

0 

0 

0 

Silkwm 

0 

0 

0 

0 

0 

6 

0 

0 

0 

L.  Mine 

0 

0 

0 

0 

0 

0 

0 

0 

3 

S.  Mine 

0 

0 

0 

0 

0 

0 

0 

10 

0 

StrikeAir 

5 

0 

0 

0 

0 

0 

0 

0 

0 

Tac  Air 

10 

0 

0 

0 

0 

0 

0 

0 

0 

Helo 

5 

0 

0 

0 

0 

0 

0 

0 

0 

Neu.Air 

1 

0 

0 

0 

0 

0 

0 

0 

0 

Tank 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Neu.Gnd 

0 

0 

0 

2 

0 

0 

0 

0 

0 

Pt  Boat 

0 

3 

0 

0 

0 

0 

0 

0 

0 

Sub 

0 

0 

1 

0 

0 

0 

0 

0 

0 

Neu.  Sea 

0 

1 

0 

0 

0 

0 

0 

0 

0 

ASCM 

6 

0 

0 

0 

0 

0 

0 

0 

0 

Hold 

0 

0 

0 

0 

0 

0 

1 

0 

0 

Silk  Air 

6 

0 

0 

0 

0 

0 

0 

0 

0 

Table  3:  Task  attribute  vector  values,  the  attributes  for  medivac  capability  (0  for  all  tasks  except 
Medivac)  and  identification  as  an  enemy  (1  for  enemy,  0  otherwise)  were  deleted  from  the  table. 

2.  Prerequisites 

Despite  the  desire  for  experimental  control,  the  experiment  was  designed  to  allow 
variance  in  task  structure  execution  at  the  unit  level  in  order  to  accommodate  differences 
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in  organization  structures  and  teams  during  the  experiment  trials.  Player  teams  were  given 
latitude  in  the  execution  of  tasks  by  providing  them  multiple  decision  points  with 
multiple  options  to  complete  tasks.  Some  resources  used  in  an  attack  might  induce  errors 
or  result  in  nonoptimal  resources  used  in  an  attack,  particularly  involving  the  coordination 
events,  e.g.,  the  players'  decisions  regarding  resource  utilization  coupled  with  the  ten 
second  window  for  coordinated  attacks,  time  pressure,  and  other  constraints.  As  a  result, 
prerequisites  leading  to  coordination  events  tended  to  be  "hard"  (see  definition  of 
hard/soft  prerequisites  in  Chapter  II),  and  prerequisites  within  the  coordination  events 
themselves  tended  to  be  "soft". 

E.         SCENARIO  DEVELOPMENT 

The  scenario  for  the  second  experiment  was  adapted  from  the  scenario  used  for 
experiment  one  and  the  joint  officer  interviews  (Berigan,  1996/Alphatech,  Inc.,  1995). 
The  goal  was  to  design  three  variants  of  the  same  scenario,  two  to  be  used  as  training 
sessions  without  triggers  and  the  other  as  the  actual  experimental  scenario,  including  two 
vignettes  within  the  experimental  scenario  to  serve  as  trigger  events  that  injected  changes 
in  mission  or  resources.  The  triggers  were  designed  to  induce  organizations  to  adapt  their 
organizational  structure.  The  training  and  experimental  scenarios  were  similar  in  format, 
but  the  training  scenarios  presented  a  significantly  lighter  workload  for  the  DMs.  This 
was  to  allow  the  players  time  to  learn  the  "knobology"  of  the  DDD  simulation,  train  as  a 
team,  ask  questions  concerning  the  scenarios,  and  practice  all  the  techniques  necessary  to 
operate  in  the  DDD  environment.  Examples  of  all  functions  to  be  encountered  in  the 
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trials  were  included  in  the  training  scenarios  to  reduce  training  effects.  No  trigger  events 
were  introduced  in  the  training  scenarios. 

After  the  experimental  scenario  design  was  completed,  a  detailed  decomposition 
of  the  mission  and  resources  was  completed  resulting  in  a  detailed  task  graph.  This  effort 
produced  the  inputs  required  by  the  modelers  at  UCONN  for  developing  the  model-based 
organizational  structure.  Inputs  required  by  the  modelers  included  such  items  as: 

•  A  list  of  tasks  with  sequencing,  including  total  number  of  occurrences  in 
the  scenario  and  the  probability  of  occurrence  during  each  phase  of  the 
mission.  See  Tables  4a  and  4b  and  Figure  3  for  details. 

•  Resources  available. 

•  Resource  capabilities. 

The  two  organizations  used  in  the  experiment  to  complete  the  mission  were 
designated  TA  (NPS's  structure  that  was  manually  derived  using  current  military 
methods)  and  NT  A  (UCONN' s  structure  that  was  model-based).  These  structures  and 
how  they  were  designed  will  be  described  later  in  this  chapter. 

After  the  experiment  scenario  was  developed  and  resource  allocation  completed 
for  each  of  the  organizational  structures,  the  scenario  was  converted  into 
OPERATIONAL  ORDERS  (OPORDs)  and  the  vignettes  containing  the  trigger  events 
were  converted  to  ORDER  MODIFICATIONS  (ORDMODs)  for  each  predetermined 
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Task 

Obstacle  1 

Obstacle  2 

Obstacle  3 

Obstacle  4 

Obstacle  5 

Prob. 

Qty 

Prob. 

Qty 

Prob. 

Qty 

Prob. 

Qty 

Prob. 

Qty 

Artillery 

L 

3 

H 

3 

H 

3 

H 

10 

H 

10 

Frog  Lncher 

L 

2 

H 

2 

H 

2 

H 

5 

H 

5 

Silkworm 

L 

1 

H 

1 

H 

1 

H 

3 

H 

3 

Mine  Land 

0 

0 

M 

1 

M 

1 

M 

2 

M 

2 

Mine  Sea 

0 

0 

H 

1 

H 

1 

H 

0 

H 

0 

Strike  Air 

L 

1 

L 

2 

L 

2 

L 

3 

L 

3 

Tactical  Air 

L 

1 

L 

1 

L 

1 

L 

2 

L 

2 

Helicopter 

L 

1 

L 

1 

L 

1 

L 

2 

L 

2 

Neutral  Air 

H 

2 

H 

2 

H 

2 

H 

10 

H 

10 

Tanks 

0 

0 

M 

1 

M 

1 

M 

2 

M 

2 

Neutral  Grd 

M 

1 

M 

1 

M 

1 

M 

3 

M 

3 

Patrol  Boat 

L 

1 

H 

1 

H 

1 

H 

3 

H 

3 

Submarine 

L 

1 

M 

1 

M 

1 

M 

3 

M 

3 

Neutral  Sea 

M 

2 

H 

2 

H 

2 

H 

10 

H 

10 

Medivac 

0 

0 

M 

1 

M 

1 

M 

2 

M 

2 

Swamp 

H 

0 

H 

~ 

H 

~ 

H 

~ 

H 

~ 

Hold 

L 

0 

L 

0 

L 

0 

L 

1 

L 

1 

Silkworm 
Air 

H 

1 

H 

1 

H 

1 

H 

3 

H 

3 

Table  4a.  Task  Occurrence  Probability  and  Quantity  Inputs 
Table  Codes:    H  -  High  probability  of  occurrence  ( 1 .0) 

M  -  Medium  probability  of  occurrence  (.6) 

L  -  Low  probability  of  occurrence  (.3) 

0  -  Zero  probability  of  occurrence 

~  -  Does  not  occur  on  roads,  full  coverage  of  areas  around  roads 
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Task 

Defend  1 

Defend  2 

Defend  3 

Defend  4 

Defend  5 

Defend  6 

Defend  7 

Pro 

b 

Qty 

Pro 

b 

Qty 

Pro 

b 

Qty 

Pro 

b 

Qty 

Pro 

b 

Qty 

Pro 
b 

Qty 

Pro 

b 

Qty 

Artillery 

0 

0 

0 

0 

H 

15 

H 

15 

H 

15 

H 

3 

H 

3 

Frog 
Lncher 

0 

0 

0 

0 

H 

10 

H 

10 

H 

10 

H 

2 

H 

2 

Silkworm 

H 

10 

H 

10 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Mine  Land 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Mine  Sea 

L 

0 

L 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Strike  Air 

H 

3 

H 

3 

H 

3 

H 

3 

H 

3 

H 

1 

H 

1 

Tactical 
Air 

H 

3 

H 

3 

M 

1 

M 

1 

M 

1 

M 

1 

M 

1 

Helicopter 

H 

3 

H 

3 

H 

2 

H 

2 

H 

2 

H 

2 

H 

2 

Neutral  Air 

H 

8 

H 

8 

H 

4 

H 

4 

H 

4 

H 

4 

H 

4 

Tanks 

0 

0 

0 

0 

H 

2 

H 

2 

H 

2 

H 

1 

H 

1 

Neutral 
Grd 

0 

0 

0 

0 

H 

3 

H 

3 

H 

3 

H 

2 

H 

2 

Patrol  Boat 

H 

4 

H 

4 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Submarine 

H 

2 

H 

2 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Neutral 
Sea 

H 

8 

H 

8 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Medivac 

0 

0 

0 

0 

M 

0 

M 

0 

M 

0 

M 

0 

M 

0 

Swamp 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Hold 

0 

0 

0 

0 

H 

1 

L 

1 

L 

1 

H 

1 

H 

1 

Silkworm 
Air 

H 

? 

H 

? 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Table  4b.  Task  Occurrence  Probability  and  Quantity  Inputs 
Table  Codes:    H  -  High  probability  of  occurrence  (1 .0) 

M  -  Medium  probability  of  occurrence  (.6) 

L  -  Low  probability  of  occurrence  (.3) 

0  -  Zero  probability  of  occurrence 

?  -  Occurrence  of  this  item  dependent  on  team  performance,  task  spawned  only  if 
team  fails  to  properly  perform  parent  task. 
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Figure  3.  Overall  Mission  Task  Graph 

initial  organizational  structure.  An  OPORD  is  a  narrative  providing  directions  on  how  the 
overall  operation  is  to  be  conducted  and  includes  such  items  as  asset  availability  and 
ownership,  tasks  to  be  accomplished,  time  lines,  and  intelligence  reports.  The  military 
issues  OPORDs  to  task  and  provide  guidance  to  the  Commander  Joint  Task  Force  (CJTF) 
and  his  subordinate  commanders.  A  copy  of  the  OPORDs  and  ORDMODs  are  included 
as  Appendix  A.  Detailed  descriptions  of  the  information  provided  to  the  players  in  the 
OPORDs  as  well  as  experimental  control  issues  such  as  scenarios,  general  situation, 
enemy  situation,  mission,  friendly  forces  and  asset  ownership,  how  the  mission  will  be 
executed  by  friendly  forces,  mission,  mission  priorities,  the  manner  in  which  the  scenario 
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should  unfold,  and  the  organizations  tested  follows. 

1.  Scenario  Background 

The  scenario  for  experiment  two  is  similar  to  the  scenario  for  NPS  experiment 
one  and  is  abstracted  from  the  OPORD  contained  in  Appendix  A. 

The  neighboring  nation  of  Yang  has  attacked  the  nation  of  Ying,  which  is  a  U.S. 
ally.  Attacking  forces  have  succeeded  in  seizing  the  Yingian  port  of  Plethora  and  the 
nearby  international  airport.  The  Yingian  government  has  requested  U.S.  assistance  in 
taking  back  the  port  of  Plethora  and  driving  Yangian  forces  from  Ying  (See  Figure  4). 

The  port  of  Plethora  is  protected  by  obstructions,  mines,  obstacles,  and  the 
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Figure  4:  DDD  Area  Map 
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presence  of  hidden  enemy  among  the  port  facility  buildings.  Two  beaches  approximately 
5  miles  south  of  the  port  are  to  be  the  sites  of  the  amphibious  assaults.  The  northernmost 
beach  (designated  "Red  Beach")  has  a  road  leading  to  the  port.  The  southernmost  beach 
(designated  "Blue  Beach")  has  a  road  leading  to  the  airfield.  Waterborne  approaches  to 
the  beaches  are/may  be  mined.  There  is  a  hill  to  the  north  of  Red  Beach  occupied  by  an 
enemy  heavy  mortar  platoon  with  a  platoon  of  infantry  for  security.  This  terrain 
dominates  both  Red  Beach  and  the  port.  It  must  be  taken  and  retained  for  a  successful 
attack  on  Red  Beach  and  the  port.  At  the  port,  but  hidden  from  view,  is  a  company-sized 
armored  counterattack  force  that  can  move  toward  Red  Beach  in  response  to  any 
amphibious  assault.  Similar  counterattack  forces  exist  at  the  airfield,  which  is  located 
about  5  miles  inland  from  Blue  Beach.  These  counterattack  forces  could  inflict  serious 
damage  if  not  interdicted  before  they  reach  either  beach.  The  off-road  terrain  between  the 
beaches,  port,  airfield,  and  hill  is  swampy  and  treacherous;  it  is  unsuitable  for  travel. 
Thus,  all  travel  must  be  on  the  two  roads.  Both  of  the  roads  may  be  mined,  but  locations 
of  the  minefields,  if  any,  are  unknown.  The  port,  airfield,  both  roads,  both  beaches,  and 
hill  are  located  within  range  of  enemy  artillery  strong-points  which  must  be  suppressed. 
The  northernmost  strong-point  can  shoot  at  Red  Beach  and  the  port.  The  southernmost 
strong-point  can  shoot  at  both  Blue  Beach  and  the  airfield.  The  artillery  pieces  are 
housed  in  reinforced  concrete  bunkers,  with  ammunition  stored  in  bunkers  deep 
underground.  Even  concentrated  air  attacks  will  not  completely  disable  the  artillery 
strong-points.  The  enemy  can  wheel  out  artillery  pieces  (from  8  to  24  at  a  time),  set  up, 
sight  in,  and  fire  within  5  minutes.  If  friendly  forces  can  get  effective  ordnance  on  target 
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in  less  than  5  minutes,  the  enemy  will  wheel  their  artillery  pieces  back  into  the  bunkers 
and  wait  until  another  time. 

Enemy  Frog  (SCUD-like)  Missile  Launchers,  capable  of  carrying  chemical 
munitions,  are  hidden  in  the  vicinity  of  both  artillery  strong-points.  They  can  emerge 
from  covered  positions,  prepare  warheads,  and  fire  missiles  within  10  minutes.  They 
must  be  destroyed  by  an  appropriate  combination  of  ordnance. 

The  submarine  threat  to  the  ARG  and  CVBG  is  considerable.  Enemy  Alfa-class 
submarines  are  known  to  be  in  the  area.  These  submarines  must  be  detected  and 
destroyed  to  protect  the  fleet. 

The  enemy  possesses  HIND  helicopters  with  the  capability  of  launching  anti-ship 
missiles.  The  CG,  DDGs,  FFGs,  and  aircraft  possess  capabilities  to  counter  these 
helicopters. 

The  enemy  has  significant  air  strike  capability  and  can  launch  anti-ship  missiles 
from  most  of  its  strike  aircraft. 

The  enemy's  Special  Forces  possess  numerous  fast  patrol  boats  that  can  fire  very 
potent  torpedoes  or  be  loaded  with  explosives  for  suicide  missions.  These  can  be  engaged 
and  destroyed  by  the  CG,  DDGs,  FFGs,  fighters,  and  Cobras. 

There  are  Silkworm  threats  throughout  the  area.  The  Silkworm  missile  launchers 
have  been  placed  in  residential  neighborhoods  because  they  know  the  U.S.  will  be 
reluctant  to  target  residential  areas.  Accordingly,  if  U.S.  warships  want  to  target  a 
Silkworm  launcher,  they  must  first  get  visual  confirmation  of  its  presence,  using  theater 
reconnaissance  (RECON)  (TARPS)  assets,  and  any  strike  mission  must  use  precision 
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guided  munitions. 

A  Joint  Task  Force  (JTF)  has  been  organized  by  a  notional  theater  commander  in 
chief,  the  CENC,  in  order  to  capture  the  port  and  airfield  to  allow  for  the  introduction  of 
follow-on  forces.  The  CINC's  ultimate  purpose  will  be  to  drive  Yangian  forces  from 
Ying  and  destroy  their  capability  for  offensive  warfare.  The  Commander,  JTF  (CJTF)  has 
at  his  disposal  an  aircraft  carrier,  an  AEGIS  cruiser,  two  DDGs,  two  FFGs,  two  LPDs, 
two  LHDs,  10  sections  of  FA- 18s,  8  sections  of  AV-8Bs,  four  sections  of  Cobras,  two 
mine  countermeasure  helos,  two  MEDIVAC  helos,  one  TRAP  reconnaissance  aircraft, 
three  AAAV  companies,  six  rifle  companies,  two  Stinger  detachments,  and  two 
engineering  platoons.  Figure  4  (page  56)  gives  a  representation  of  the  operation  area. 

2.  Friendly  Situation  and  Assets 

The  following  groups  the  assets  in  generic  component  task  groups  or  units;  the 
DM  that  will  "own"  and  control  each  asset  during  DDD  play  is  dependent  on  the 
organization  structure.  (See  Figures  5  and  6  for  details  about  organizational  structures) 

There  are  a  theater-level  Joint  Force  Air  Component  Commander  (JFACC)  and 
other  friendly  forces  conducting  independent  operations  against  the  enemy  in  Ying,  not 
in  concert  with  the  JTF.  The  presence  of  these  independent  friendly  units  and  neutral 
platforms  forced  the  CJTF  to  identify  contacts  prior  to  attacking  to  ensure  friendly  and 
neutral  forces  were  not  destroyed.  The  identification  process  also  provided  information 
needed  by  the  DMs  to  assign  the  right  mix  of  assets  to  successfully  attack  a  hostile  unit 
when  appropriate.  The  aircraft  from  the  CVBG  available  to  support  the  JTF  are  the  10 
sections  of  FA- 18s,  8  sections  of  AV-8Bs  and  1  FA- 18  TARPS  aircraft.  The  FA- 18s  with 
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laser  guided  bombs  can  attack  FROG  launchers  and  confirmed  Silkworm  (land-based 
anti-ship  missile)  missile  sites,  or  they  can  be  used  for  anti-air  warfare,  and  to  man 
combat  air  patrol  stations.  The  AV-8Bs  can  be  used  to  provide  close  air  support  to  the 
ground  troops.  The  FA- 18  TARPS  can  be  used  for  reconnaissance  only. 

MEU  1  is  composed  of  one  Advanced  Amphibious  Assault  Vehicle  (AAAV) 
mounted  infantry  company,  two  MV-22  Osprey  mounted  heliborne  infantry  companies, 
one  division  of  AH-1W  Cobra  attack  helicopters,  one  division  of  mine  countermeasures 
(MCM)  helicopters  (indivisible),  one  engineer  platoon,  and  a  division  of  MEDEVAC 
helicopters  (indivisible).  MEU  2  is  composed  of  two  AAAV  mounted  infantry 
companies,  one  V-22  mounted  heliborne  infantry  company,  one  division  of  AH-1W 
Cobra  attack  helicopters,  one  division  of  mine  countermeasures  (MCM)  helicopters 
(indivisible),  one  engineer  platoon,  and  a  division  of  MEDEVAC  helicopters 
(indivisible).  Each  MEU  will  be  considered  to  have  an  unmanned  aerial  vehicle  (UAV) 
flying  in  its  support  for  the  duration  of  the  operation.  The  players  will  not  control  the 
UAVs  but  their  presence  will  be  represented  by  the  nearly  omniscient  battlefield  picture 
each  MEU  will  possess. 

As  mentioned  previously,  the  assets  were  designed  so  that  single  assets  could  not 
successfully  accomplish  a  coordination  event  task;  coordination  was  required  to  assign 
multiple  assets  to  achieve  the  right  mix  for  a  successful  attack.  Various  combinations  of 
assets  are  capable  of  accomplishing  each  coordination  task.  Single  assets  could  make 
repeated  attacks  on  a  target,  but  in  this  experiment,  DDD-DI  would  assign  a  penalty  and 
the  attacking  unit  would  not  be  assured  of  destroying  the  target.  This  was  done  to  force 
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coordination  where  the  experimental  designers  wanted  it  to  occur. 

The  asset-to-task  matching  was  implemented  on  DDD-IH  via  specification  of  task 
resource  requirements  and  asset  resource  capability.  Each  task  and  asset  is  associated 
with  a  9-dimension  resource  vector  R  =  (rl,  r2, ...  ,  r9)  as  shown  in  table  2,  with 
components  that  correspond  to  task  requirements  or  combat  capability/potential  in 
various  categories  (r/s)  For  example,  rO  =  air  combat,  rl  =  sea  combat, ...,  r6  = 
holding/occupying,  r7  =  sea  mines,  r8  =  land  mines,  r9  =  medivac.  Assigning  a  set  of 
values  to  R  for  a  specific  task  (see  Table  3)  establishes  what  mix  of  assets,  with  their 
corresponding  sum  of  R  values,  is  sufficient  to  correctly  process  that  task.  Thus, 
mine-clearing  helicopters  have  relatively  high  values  assigned  to  r7  corresponding  to  the 
combat  potential  of  that  unit  for  sea  mine  tasks.  Other  assets  with  other  primary 
capabilities  would  have  lower  values  assigned  to  r7,  or  zero  (Kemple,  et  al.,  1996).  A 
coordination  event  such  as  taking  a  beach  would  require  sufficient  values  in  the  rs 
elements  for  ground  assault,  armor,  and  hold  that  could  not  be  satisfied  by  any  one  asset 
but  could  be  satisfied  by  several  different  combinations  of  assets.  The  R  values  of  all 
assets  assigned  to  attack  a  task  are  totaled  within  each  r{  to  determine  whether  the 
assigned  units  have  sufficient  collective  combat  potential  to  complete  the  task.  If  the 
combined  R  values  of  the  assigned  assets  are  greater  than  or  equal  to  each  component  of 
the  R  values  of  the  task,  the  team  is  credited  with  a  successful  attacks  without  losing 
points.  If  the  combined  R  of  the  assigned  assets  are  less  than  R  of  the  task  in  any 
component  (inadequate  attack),  the  target  is  destroyed  but  the  team  is  penalized  a 
predetermined  number  of  points.  If  assets  with  collective  r,'s  =  0  in  required  combat 
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potential  areas  are  assigned  (an  inappropriate  attack),  the  target  is  not  killed  and  the  team 
again  loses  points. 

A  summary  of  the  assets  available  and  assigned  owners  is  shown  in  Table  5.  The 
combat  potential  for  each  asset  is  shown  in  Table  2.  Penalty  points  are  levied  in  a  binary 
fashion;  either  the  task  is  completed  successfully  and  no  points  are  deducted  or  it  is  not 
and  the  maximum  penalty  points  are  deducted. 

3.  Mission 

In  order  to  successfully  complete  a  trial,  a  set  of  coordination  and  background 
tasks  must  be  completed  in  priorities  and  sequence  within  40  game  minutes.  The  CJTF 
and  his  subordinate  commanders  (the  team  participating  in  the  trials)  must  accomplish  the 
following: 

Ground  Component:  To  secure  the  port  and  airfield  of  Plethora,  allowing  for  the 
introduction  of  follow-on  forces.  In  order  to  achieve  these  objectives,  enemy  forces  and 
defenses  must  be  identified,  engaged  and  defeated. 

Maritime  Component:  To  support  the  amphibious  operation  with  close  air 
support  (CAS),  naval  surface  fire  support  (NSFS),  mine  countermeasures,  and  air  defense 
and  medivac  assets,  and  to  defend  the  CVBG  and  ARG  from  air,  surface,  and  subsurface 
threats. 

The  specific  DM-to-task  assignment  is  dependent  on  the  organizational  structure 
and  assignment  of  resources. 
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Platform 

Owner  in  TA 

Owner  in  NTA 

Total  Qty 

DDG 

DM  1/DM  3(1  ea) 

DM4 

2 

FFG 

DM2 

DM5 

2 

CG 

DM2 

DM4 

1 

CV 

DM2 

DM0 

1 

LSD 

DM3 

DM4 

1 

LHA 

DM  1 

DM5 

1 

LPD 

DM  l/DM3(lea) 

DM  4/DM  5(  lea) 

2 

Eng  Pit 

DM4/DM5(lea) 

DM  4/DM  5(1  ea) 

2 

Rifle  Company 

DM  4/DM  5  (3  ea) 

DM  1/DM  3  (3  ea) 

6 

Stinger  Detachment 

DM  l/DM3(lea) 

DM  1/DM  3  (lea) 

2 

Cobra  Section 

DM  4/DM  5  (2  ea) 

DM  2/DM  3  (2  ea) 

4 

CAS  Section 

DM2 

DM0 

8 

Fighter  Section 

DM2 

DM5 

10 

Huey  Med 

DM  l/DM3(lea) 

DM  4/DM  5(1  ea) 

2 

MCM  Huey 

DM  l/DM3(lea) 

DM  4/DM  5(1  ea) 

2 

RECON  Aircraft 

DM0 

DM0 

1 

AAAV 

DM4(2)/DM5(1) 

DM  1(2)/DM3(1) 

3 

MV-22 

DM4(1)/DM5(2) 

DM  1(1)/DM3(2) 

3 

Table 

5:  Assets,  owners,  anc 

quantities  of  each  ava 

ilable 
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DM  0  (4.0) 

Reconn  (1) 

_^— — • — "  ' "" ■ 

DM  1  (4.1) 

DM  2  (4.2) 

DDG    (1) 
Cobra  (2) 
MED    (1) 
MCM   (1) 

CV        (1) 
CG        (1) 
FFG      (2) 
VF        (10) 
CAS      (8) 

DM  4  (4.1.1) 

Eng.          (1) 
Rifle  Co.  (3) 
Stinger      (1) 

4. 

Exe 

Figure  5:  Traditiona 
cution 

DM  3  (4.3) 

DDG    (1) 
Cobra  (2) 
MED    (1) 
MCM   (1) 

DM  5  (4.3.1) 

Eng.          (1) 
Rifle  Co.  (3) 
Stinger     (1) 

Each  MEU  simultaneously  lands  an  AAAV-mounted  company  on  the  beach. 
MEU  1  attacks  Red  Beach,  and  MEU  2  attacks  Blue  Beach.  MEU  1  simultaneously 
secures  the  commanding  terrain  overlooking  Red  Beach  and  the  port  with  its  heliborne 
company.  Once  the  beaches  and  commanding  terrain  are  secure,  the  two  AAAV-mounted 
companies  proceed  down  the  roads  from  their  respective  beaches,  clearing  minefields 
with  the  engineer  platoons,  killing  counterattack  forces  with  the  Cobras,  and  conducting 
MEDEVACs  as  necessary. 
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DM  1  (4.1) 


Rifle  Co.       (3) 
Stinger  (1) 


DM  0  (4.0) 


CAS  (8) 

CV  (1) 

RECON    (1) 


DM  2  (4.2) 


Cobra        (2) 


DM  3  (4.3) 

Rifle  Co. 

(3) 

Cobra 

(2) 

Stinger 

(1) 

DM  4  (4.2.1) 

Eng. 

(1) 

Med. 

(1) 

MCM 

(1) 

CG 

(1) 

DDG 

(2) 

DM  5  (4.2.2) 

Eng. 

(1) 

Med. 

(1) 

MCM 

(1) 

VF 

(10) 

FFG 

(2) 

Figure  6:  Nontraditional  Architecture 


Each  MEU  has  an  unmanned  aerial  vehicle  (UAV)  (launched  from  the  ARG) 
airborne  for  the  duration  of  the  operation.  The  UAVs  keep  the  artillery  strong  points  and 
the  suspected  FROG  sites  under  constant  surveillance,  so  that  NSFS  or  CAS  assets  can  be 
brought  to  bear  immediately  if  they  are  needed. 

Once  the  roads  have  been  cleared,  the  AAAV-mounted  companies  from  MEU  1 
and  MEU  2  attack  the  port  and  the  airfield,  respectively.  MEU  2's  AAAV-mounted 
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company  is  joined  in  its  attack  by  a  helibome  company  from  MEU  2.  It  is  important  that, 
once  the  AAAV-mounted  companies  land  on  the  beach,  the  airfield  and  port  be  taken  as 
quickly  as  possible,  before  the  enemy  has  a  chance  to  organize  his  defense  and  send 
reinforcements.  It  is  desired  that  final  assaults  on  the  airfield  and  port  be  conducted 
simultaneously,  in  order  to  present  the  enemy  commander  with  the  most  confusing, 
dilemma-filled  environment  possible,  but  if  one  attack  must  be  conducted  before  the 
other,  the  airfield  takes  priority.  If  the  airfield  attack  is  held  up  for  any  reason,  the  port 
attack  should  wait  to  retain  the  synergism  of  concurrent  attacks;  if  the  port  attack  is  held 
up,  the  airfield  attack  should  go  forward. 

Due  to  hydrographic  limitations,  the  ARGs  and  the  CVBG  have  to  be  significantly 
separated  during  the  operation,  enough  to  preclude  them  from  being  under  a  joint  air 
defense  umbrella  provided  by  the  AEGIS  cruiser.  Thus,  the  AEGIS  cruiser  should  remain 
with  the  CVBG,  but  position  itself  so  that  it  can  rapidly  move  from  the  CVBG  to  the 
ARG  if  that  becomes  necessary.  Additionally,  the  two  destroyers  are  to  be  inshore, 
providing  NSFS  support,  while  the  frigates  are  the  primary  anti-submarine  warfare 
platform  for  the  CVBG.  The  frigates  performing  anti-submarine  warfare  should,  like  the 
AEGIS  cruiser,  position  themselves  so  that  they  can  quickly  move  to  support  the  ARG  if 
that  is  necessary. 

The  ARG  launches  the  Marines  for  the  initial  assault  on  Red  and  Blue  Beaches. 
The  ARG  will  launch  the  mine  countermeasures  helicopters,  Cobras,  MEDEVAC 
aircraft,  the  air  assault  for  MEU  2's  attack  on  the  airfield,  etc.  when  called  to  do  so.  The 
destroyers  will  provide  NSFS  to  suppress  the  artillery  strong  points  ashore  when 
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requested  to  do  so  by  either  of  the  MEUs. 

The  CVBG  is  to  keep  two  sections  of  FA- 18s  with  precision  guided  munitions  on 
standby  at  all  times:  one  to  be  used  against  FROGs  (in  support  of  the  MEUs)  and  the 
other  against  Silkworms  (in  support  of  the  CVBG  or  ARG).  The  CJTF  will  be  launch 
authority  for  both  sections.  The  CVBG  is  to  also  provide  two  sections  per  hour  of  air 
defense  aircraft  (FA- 18  or  F-14),  with  one  combat  air  patrol  station  over  the  CVBG  the 
other  over  the  ARG. 

If  a  suspected  Silkworm  launcher  is  detected,  it  must  be  identified  first  by  the  FA- 
18  TARP  before  it  can  be  destroyed.  A  Silkworm  launcher  detected  at  the  northernmost 
site  threatens  the  CVBG,  at  the  southernmost  site,  the  ARG. 

5.  Priorities 

The  JTF's  overall  priority,  and  the  priority  within  the  ground  component,  is  MEU 
2's  attack  on  the  airfield,  because  the  initial  buildup  of  friendly  forces  can  be  most 
quickly  and  effectively  achieved  through  air  transport. 

The  following  CJTF's  priorities  were  given  to  the  players  within  the  maritime 
component:  if  both  the  ARG  and  CVBG  are  threatened  by  the  enemy,  the  ARG  has 
priority  of  support  against  submarine  threats,  fixed-wing  air  threats,  and  patrol  boats.  If 
there  is  a  threat  of  an  air  attack  against  the  ARG,  the  ARG  should  get  the  AEGIS  cruiser 
and  a  combat  air  patrol. 

The  frigates,  performing  anti-submarine  warfare,  and  the  AEGIS  cruiser, 
performing  anti-  air  warfare,  stay  with  the  CVBG  unless  a  necessity  occurs  with  the 
ARG,  because  the  CVBG  is  considered  a  more  likely  target  for  the  enemy.  The  CVBG 
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has  priority  against  land-based  Silkworm  sites  and  helicopters. 

F.       DEVELOPMENT  OF  THE  TRAINING  SCENARIOS 

In  order  to  familiarize  the  subjects  with  the  general  situation  in  the  scenario  and 
the  DDD  in  simulation  (the  operational  context  and  activities  required  such  as  requesting 
assets,  communicating  using  voice  and  preformatted  message  sets,  et  cetera),  I  created 
two  training  scenarios  based  on  the  experimental  scenario.  The  training  scenarios  were 
identical  to  the  experiment  scenario,  except  they  did  not  contain  as  many  coordination 
events,  as  high  a  workload,  or  trigger  events. 

1.  Development  of  Organizational  Structures 

The  design  of  the  experiment  required  two  organizational  structures  to  test  the 
hypotheses.  One,  called  the  Traditional  Architecture  (TA)  was  designed  based  on  military 
principles,  the  other  organizational  structure  was  provided  by  the  modelers  at  UCONN 
and  was  based  on  minimizing  coordination  between  DMs  (external  coordination). 
Transfer  of  assets  between  DMs  was  not  allowed.  This  organizational  structure  was  called 
the  Nontraditional  Architecture  (NT A).  The  organizations  are  structurally  different,  yet 
logically  and  efficiently  designed. 

a.  Traditional  Architecture  Organizational  Structure 

The  TA  organizational  structure  developed  at  NPS  was  based  on  the 
principles  for  force  structure  organizations  delineated  in  Joint,  Service,  and  Component 
Doctrine.  The  principles  were: 

1 .  Design  the  organization  structure  in  a  way  that  clearly  defines  the  structure  of 
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authority,  responsibility,  and  ownership  of  assets,  establishing  a  network  of  relationships 
among  commanders  delineating  communications  channels,  chain  of  command,  authority 
and  responsibility,  and  unity  of  command. 

2.  Provide  framework  for  building  task  forces  and  task  groups. 

3.  Provide  a  reasonable  span  of  control  (varies  with  each  situation) 

"...  command  and  control  organizations  must  be  able  to  handle  and 
disseminate  information  efficiently.  We  generally  favor  more 
decentralized  organizations,  which  can  process  information  more  quickly, 
to  maintain  a  high  tempo  of  operations."(Marine  Corps  Doctrine 
Publication  6,  1996) 

4.  Provide  Unity  of  Effort:  Unity  of  effort  implies  ..."that  all  the  participants  in  an 
operation  strive  to  shape  their  efforts  toward  a  common  goal.  It  does  not  imply  rigid, 
centralized  control,  but  rather  cooperation,  coordination,  and  mission  control. "(Naval 
Doctrine  Publication  6,1996) 

5.  Provide  Simplicity  of  communications  -  Fully  connected  (open) 
communications  between  nodes  does  not  constrain  the  design  of  task  organizations  or 
adaptation. 

6.  Provide  Economy  of  force  -  Economy  of  forces  means  that  the  minimum 
quantity  of  personnel,  equipment,  and  other  necessary  resources  are  committed  to  the 
mission  to  ensure  overwhelming  force  can  be  applied.  Economy  of  force  minimizes  the 
cost  of  the  mission  in  terms  of  casualties  and  damage  during  the  mission  and  in  monetary 
terms. 
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7.  Organize  and  control  battle  space  and  manage  information. 

Other  factors  that  influenced  the  selection  of  the  organizational  structure  were 
pattern  matching,  history,  and  past  experiences.  Pattern  matching  refers  to  the  aspect  of 
humans  to  look  for  similarities  or  patterns  between  a  current  problem  or  situation  and 
previous  experiences,  and  then  tailor  the  solution  for  that  problem  to  the  present  one. 
Figure  7  shows  the  organizational  structure  and  ownership  of  assets  for  the  traditional 
organization.  (Figures  7  and  8  are  replicates  of  Figures  5  and  6,  placed  here  for  the 
readers  convenience) 

In  Figure  7,  the  TA  organization,  DM  0  would  be  equivalent  to  the  CJTF  with 
overall  responsibility  for  the  operation.  DMs  1  and  3  would  equate  to  ARG  1  and  2 
respectively.  DM  2  would  be  the  carrier  battle  group  commander,  providing  air  support 
for  the  operation,  the  joint  force  air  component  commander  (JFACC),  and  handling  the 
duties  of  the  maritime  component  commander  (MCC).  DMs  4  and  5  would  be  the  MEU  1 
and  2  commanders. 
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DM  1  (4.1) 


DDG  (1) 

Cobra  (2) 

MED  (1) 

MCM  (1) 


DM  0  (4.0) 

Reconn  (1) 

DM  2  (4.2) 

CV        (1) 

CG        (1) 

FFG      (2) 

VF        (10) 

CAS     (8) 

DM  4(4.1.1) 


Eng.  (1) 

Rifle  Co.  (3) 
Stinger      (1) 


DM  3  (4.3) 

DDG    (1) 
Cobra  (2) 
MED    (1) 
MCM   (1) 

DM  5  (4.3.1) 

Eng.          (1) 
Rifle  Co.  (3) 
Stinger     (1) 

Figure  7:  Traditional  Architecture  (same  as  Figure  5,  provided  here  for  convenience) 

b.  Nontraditional  Architecture  Organization  Structure 

In  order  for  the  UCONN  modelers  to  design  an  organizational  structure 
based  on  the  mission,  they  needed  detailed  information  about  the  mission,  tasks,  task 
structure,  probabilities  of  encountering  each  task/subtask,  assets,  and  asset  capabilities. 
The  models  then  used  to  design  an  organizational  structure  and  assign  asset  ownership  to 
the  structure  based  on  expected/probable  tasks  such  that  workload  between 
DMs  would  be  evenly  distributed  and  minimum  coordination  would  be  required  between 
nodes.  Figure  8  shows  the  organization  structure  and  ownership  of  assets  for  the 
nontraditional  organization.  In  the  NTA  organization,  DM  0  would  again  equate  to  the 
CJTF,  but  the  other  DM's  do  not  fit  any  of  the  current  military  component  terms;  they  are 
unique  in  their  structure. 
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c.  Differences  Between  The  Traditional  and  Nontraditional 

Architectures 

Figures  7  and  8  show  the  command  relationships  between  the  DMs  in  the 

TA  and  NTA  organizations.  At  first  glance,  the  architectures  do  not  seem  to  be 

significantly  different.  Closer  examination  of  the  NTA  structure  shows  that  "jointness"  of 

the  organization  has  been  pushed  to  the  next  lower  echelon  in  the  chain  of  command 

when  compared  with  the  TA  structure.  This  is  similar  to  current  military  thinking.  Recent 

technology  advances  are  obviating  much  of  the  interoperability  problem  in 

communications  between  the  services,  permitting  joint  operations  commands  to  be 

inserted  into  lower  echelons  of  joint  operations  while  also  permitting  flattening  of  the 

organizational  structure,  thus  increasing  the  overall  responsiveness  of  the  command. 

2.  Total  Asset  Determination 

To  eliminate  another  factor  in  the  design  of  the  experiment,  both  organizations 
(TA  and  NTA)  were  assigned  the  same  number  of  units  and  platforms,  with  the  same 
combat  potential,  to  achieve  the  same  tasks  and  complete  the  mission.  We  desired  to 
ensure  sufficient  resources  with  associated  capabilities  were  provided  to  the  organizations 
to  accomplish  the  mission  before  and  after  the  triggers  and  to  ensure  that  both 
organizations  were  required  to  coordinate  both  internally  and  externally.  Therefore,  it  was 
necessary  to  perform  an  iterative  process,  closely  integrating  asset  design  with  the 
scenario  and  trigger  design  efforts  to  determine  the  proper  quantities  and  capabilities  of 
the  assets.  It  was  necessary  to  define/refine  platform  resource  vectors  and  task  attribute 
vectors  (Explained  before)  to: 
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1.  Require  coordinated  action  by  two  or  more  units/platforms  to  accomplish 
mission  tasks. 

2.  Ensure  that  more  than  one  combination  of  platforms  could  be  used  to 
accomplish  mission  tasks. 

3.  Ensure  sufficient  assets  were  provided  to  accomplish  missions  before  and  after 
the  triggers  were  invoked. 

4.  Organize  task  forces  into  capable  subordinate  elements. 

5.  Organize  overall  mission  into  manageable  parts. 


DM  1  (4.1) 


Rifle  Co. 
Stinger 


(3) 
(1) 


DM  0  (4.0) 


CAS  (8) 

CV  (1) 

RECON    (1) 


DM  2  (4.2) 


Cobra        (2) 


DM  3  (4.3) 

Rifle  Co. 

(3) 

Cobra 

(2) 

Stinger 

(1) 

DM  4  (4.2.1) 

Eng. 

(1) 

Med. 

(1) 

MCM 

(1) 

CG 

(1) 

DDG 

(2) 

DM  5  (4.2.2) 

Eng. 

(1) 

Med. 

(1) 

MCM 

(1) 

VF 

(10) 

FFG 

(2) 

Figure  8:  Nontraditional  Architecture  (same  as  Figure  6,  provided  here  for  convenience) 
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G.         CONDUCT  OF  EXPERIMENT 

An  overview  of  the  experiment  including  the  facilities,  equipment,  lead  team, 
players,  and  training  is  provided  in  this  section.  Most  of  the  equipment  and  facilities  were 
the  same  as  used  in  experiment  one. 


1.  Experiment  Setup 

The  second  NPS  A2C2  experiment  was  conducted  in  the  secure  Systems 
Technology  Lab. 

a.    Physical  Facilities 

The  scenario  was  presented  to  the  player  teams  on  a  distributed, 
interactive,  computer  simulation  running  on  seven  SUN  SPARC™  model  20 
workstations  (one  for  each  of  the  six  DMs  and  one  for  the  DDD-IQ  controller's  station). 
The  Systems  Technology  Laboratory  at  the  Naval  Postgraduate  School  in  Monterey,  CA 
was  utilized  for  conducting  the  experiment.  It  provides  an  area  where  access  is  controlled 
so  interrupts  and  disturbances  are  minimized.  Although  all  players  from  a  team  were 
located  in  the  same  room,  dividers  were  placed  between  them  to  physically  obstruct  their 
views  of  the  other  players'  screens.  Communication  among  players  was  restricted  to 
Preformatted  computer  messages  built  into  the  simulation  and  recorded  voice 
communications  over  two  separate  channels  connected  to  common  headsets.  The  ability 
to  communicate  between  DMs  is  an  important  factor  affecting  organizational  structure 
and  coordination  of  efforts.  DM  nodes  in  an  organizational  structure  represent  the 
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decision  makers  or  commanders  of  the  resources  that  are  responsible  for  completing 
assigned  tasks  in  the  overall  mission.  For  the  purposes  of  the  experiment,  "stovepipe"  C4I 
systems  have  been  eliminated  in  the  scenario  and  all  DMs  easily  communicate  with  each 
other  by  voice  or  electronic  messages. 


b.         Lead  Team 

A  group  of  nine  NPS  officer  students  from  the  Joint  C4I  Systems 
Curriculum  in  their  last  year  were  designated  as  the  "lead  team"  for  this  experiment.  The 
lead  team  was  composed  of  officers  from  all  four  branches  of  the  armed  forces.  In 
addition,  all  members  had  recent  operational  experience.  Since  I  had  been  involved  as  an 
associate  researcher  on  the  A2C2  project  for  the  past  year,  I  headed  the  lead  team. 

The  lead  team  performed  such  tasks  as  preparation  of  training  materials  for 
the  subjects,  conduct  of  subject  training,  setup  of  the  physical  space,  debugging  the 
simulation,  piloting  the  scenario's  implementation  in  the  simulation,  conduct  of  the 
experimental  runs,  and  data  collection.  The  lead  team  members  provided  invaluable 
suggestions  and  advice  concerning  all  of  the  above  tasks,  developing  the  scenario,  and 
filled  many  gaps  in  the  author's  experience. 

c  Test  Subjects  Used 

The  test  subjects  were  23  military  officer  students  from  the  Joint  C4I 
Systems  and  Space  Systems  Operations  Curricula  plus  a  recent  graduate  from  NPS.  The 
subjects  were  organized  into  six  four-person  teams  with  two  confederates  rounding  the 
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teams  up  to  six.  The  confederates  were  three  members  of  the  lead  team  who  augmented 
the  player  teams.  The  confederates  were  used  to  perform  the  functions  of  one  of  the  DMs 
at  each  of  the  two  lowest  echelons.  By  using  the  confederates,  we  were  able  to  form  six- 
player  teams  from  the  24  subjects.  The  teams  were  formed  by  the  experimenters  with 
participants  distributed  according  to  military  occupational/war  fighting  specialty  and 
branch  of  service,  to  the  extent  that  was  possible  given  the  demographics  of  the  sample. 
Table  6  shows  the  composition  of  the  teams  by  branch  of  service,  type  of  service 
(operational  or  support),  and  curricula  Since  there  was  a  fairly  significant  difference 
between  the  operational  experience  of  the  subjects,  the  experimenters  were  concerned 
that  some  subjects  would  be  more  familiar  than  others  with  the  appropriate  tactics  to 
employ  in  a  given  situation,  and  that  this  might  bias  the  performance  measures  chosen  as 
dependent  variables.  In  order  to  help  protect  against  such  an  effect,  the  scenario  and  the 
operations  orders  were  tailored  to  facilitate  a  step-by-step  approach  to  each  situation. 
This  approach  further  aided  the  experimenters'  attempt  to  steer  the  subjects  toward  the 
coordination  events  that  were  of  primary  interest  in  the  experiment. 

d.         DDD-HI  Simulation 

The  experiment  was  conducted  using  the  Distributed  Dynamic 
Decisionmaking-lH  (DDD-ffl)  paradigm  simulation.  Earlier  variants  of  the  DDD  had 
been  used  extensively  to  study  decisionmaking  in  the  Navy's  Composite  Warfare 
Commander  (CWC)  organizational  structure  and  civilian  sector  organizational 
experiments.  Last  year  DDD  was  extended  to  fit  the  general  requirements  of  tier-I 
experimentation  for  the  A2C2  project,  and  was  further  enhanced  to  meet  the  specific 
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requirements  of  the  current  experiment.  DDD  is  not  a  tactical  model  on  the  level  of 
RESA,  JTLS,  MTWS,  CBS,  or  AWSIM  which  are  driven  by  extensive  and  detailed 
parametric  databases.  DDD  is  a  more  abstract  game  that  uses  performance  and  resource 
vectors  to  describe  entity  capabilities  at  a  higher  level  of  abstraction.  The  result  is  a 
simulation  that  appears  to  operate  like  the  combat  event  simulations  above,  but  is  easier 
to  use  to  develop  scenarios  and  requires  a  much  shorter  time  to  train  subjects.  DDD-HI 
contains  data  collection  and  variable  manipulation  capabilities  that  make  it  very 
appropriate  for  a  research  environment.  For  a  more  detailed  explanation  of  DDD-III, 
including  characteristics,  see  Higgins  (1996). 
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Code# 
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Meaning  of  Codes 

1 

Branch  of 
Service 

N  =  Navy    A  =  Army   F  =  Air  Force    M  =  Marine 

Corps 

2 

Type  of 
Service 

O  =  Operational                S  =  Support 
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Curricula 

C  =  C4I    S  =  Space  Systems  Operations    0  =  Ops 
Research 

Table  6.  Composition  of  the  Teams  of  Players  for  the  second  NPS  Experiment 


Matching  of  Subjects  to  Task/Organizational  Structure 
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The  research  team  wanted  to  assign  the  subjects  to  a  particular  node  at 
each  level  of  hierarchy  in  the  organizational  structures  throughout  the  training  and  data 
runs;  if  a  subject  began  the  training  runs  as  the  CJTF  for  his  team,  for  example,  he  would 
remain  CJTF  throughout  the  experiment.  In  addition,  it  was  desired  to  keep  the  subjects 
involved  at  each  level  in  of  the  hierarchy  in  the  organizational  structures.  To  facilitate  this 
requirement,  the  confederates  were  assigned  to  DM  1  and  DM  5  nodes  in  the  traditional 
organization  and  to  DM  1  and  DM  4  nodes  in  the  nontraditional  organization. 

To  the  greatest  degree  possible,  the  experimenters  and  lead  team  attempted 
to  match  the  subjects  to  positions  in  the  organizational  structure  for  which  they  had  some 
operational  experience. 

2.  Opera tionalization  of  Task/Organizational  Structures 

The  organizational  structures  and  the  task  structures  were  operationalized  in  three 
significant  respects:  asset  structure,  communications  structure,  and  information  structure. 

a.         Asset  Structure 

The  scenario  was  designed  so  that  some  tasks  (coordination  events)  could 
not  be  successfully  performed  with  a  single  asset.  The  assets  required  to  perform  a  task 
requiring  a  coordinated  attack  may  belong  to  one  or  more  DMs.  Unlike  experiment  1, 
assets  could  not  be  transferred  between  DM's  in  this  experiment.  Instead  the  DM 
initiating  the  attack  must  coordinate  the  attack  with  resources  he  owns  or  he  must 
coordinate  with  other  DMs  to  successfully  perform  the  task.  For  example,  if  MEU  2  was 
attacking  the  beach  and  required  support,  the  experimenters  wanted  MEU  2  to  request 
support  from  the  necessary  asset  (the  DDG)  to  shell  the  beach,  rather  than  allowing  the 
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DM  owning  the  DDG  to  transfer  it  to  MEU  2.  This  was  enforced  by  DDD-IH  to  ensure 
that  the  external  coordination  events  actually  occurred.  Table  2  shows  each  platform's 
resource  or  combat  potential  vector  and  the  task  attribute  vector  (enemy  force  combat 
potential)  required  for  a  successful  attack. 

b.  Communications  Structure 

Communications  in  this  experiment  consisted  of  preformatted  messages 
and  data  transfer  using  the  DDD-IH  simulation  and  two  channels  of  open  voice 
communications.  Open  communications  were  allowed  between  all  DMs,  simulating  the 
projected  future  integrated  C4I  systems  ability  to  provide  a  common  operational  picture 
(COP)  as  described  in  the  next  section. 

Copies  of  all  messages  sent  by  a  decisionmaker  were  automatically 
forwarded  to  the  next  higher  level  in  the  sender's  hierarchy.  If  a  lower-level  unit 
communicated  with  another  low-level  unit,  copies  of  the  messages  were  automatically 
sent  to  the  intermediate  commander  in  his  chain  of  command.  If  the  intermediate  level 
commander  communicated  with  a  lower  level  unit,  a  copy  of  his  message  was 
automatically  forwarded  to  the  CJTF. 

Both  voice  channels  were  open  so  that  all  DMs  could  monitor  all 
communications.  The  recommendation  to  the  subjects  was  to  have  one  channel  for  all 
routine  communications  and  the  other  channel  be  used  by  DMs  who  were  coordinating  an 
attack. 

c.  Information  Structure 
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One  of  the  major  assumptions  for  this  experiment  is  the  existence  of  a 
common  operational  picture  (COP)  and  a  fully  integrated  communications  network  which 
allows  all  commanders  at  all  levels  to  have  a  common  view  of  the  battlespace;  they  see 
the  same  threats,  at  the  same  time  and  can  easily  and  readily  communicate  up,  down,  and 
across  the  chain  of  command.  Since  our  purpose  was  to  test  organizational  structures  in  a 
future  environment  of  shared,  global  information,  the  COP  was  implemented  in  our 
experiment.  When  one  decisionmaker  in  the  organization  saw  a  threat  or  task,  others  saw 
it  too.  To  provide  identification  of  a  target,  the  DM  whose  sensors  held  the  contact  had  to 
fuse  that  information  into  the  COP  by  sending  it  to  the  other  DMs. 
3.  Training 

The  proper  training  of  the  subjects  in  the  operation  of  the  simulation  and  the 
requirements  of  the  operations  order  (OPORD)  was  vital  to  the  success  of  the  data  runs. 
Two  aspects  of  this  training  were  significant:  the  training  materials  that  the  lead  team  and 
experimental  team  generated,  and  the  conduct  of  the  training  itself. 

a.  Training  Materials 

Three  primary  training  aids  were  developed  for  the  experiment:  an 
operational  order  (OPORD)  which  transformed  the  scenario  into  a  directive  for  execution 
of  the  operation,  a  tutorial  designed  to  aid  the  subjects  in  using  the  DDD-III,  and  the 
scenario  developed  for  the  training  portion  of  the  experiment. 

(1)  Operations  Order:  When  a  military  operation  or  exercise  is  conducted, 
an  OPORD  is  issued  as  a  directive  listing  mission  requirements  including  resources, 
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threats,  constraints,  and  options.  This  OPORD  provides  the  unit(s)  that  will  conduct  the 
mission  the  general  situation,  enemy  forces,  friendly  forces,  assets  available,  the  mission 
requirements,  how  the  mission  will  be  executed,  logistics,  and  command  and  control 
information.  This  was  the  format  used  to  provide  the  subjects  the  information  needed  to 
execute  the  scenario. 

(2)Tutorial:  The  tutorial  provided  the  link  between  the  OPORD  and 
DDD-IH.  It  described  the  simulation,  its  display  and  user  interface,  functions  of  the 
mouse,  requesting,  launching,  moving  and  transferring  assets,  identifying  and  attacking 
threats,  and  use  of  the  communications  system  to  view,  send,  and  receive  messages.  The 
tutorial  listed  and  described  in  detail  the  objects  that  appear  on  the  DDD-HI  screen, 
including  terrain  features,  and  provided  a  description  of  the  organization  structures  used 
in  the  experiment  and  how  they  are  implemented  in  DDD-IH.  A  quick  reference  sheet 
was  provided  that  concisely  described  all  the  objects  on  the  screen  and  possible  asset 
combinations  that  could  be  used  to  destroy  enemy  threats,  abbreviations  used  by  DDD,  a 
list  of  assets,  and  the  platforms  on  which  they  were  carried. 

(3)Training  Scenarios:  The  training  scenarios  were  devised  to  help  the 
subjects  learn  about  the  simulation  and  OPORD,  and  allow  them  to  become  proficient  in 
the  skills  that  would  enable  them  to  successfully  complete  the  mission  and  coordination 
efforts  during  the  trials.  The  experimenters  did  not  want  to  overload  the  subjects  during 
the  training  phase,  so  the  training  scenarios  were  devised  with  a  lighter  workload.  These 
scenarios  were  written  by  the  author,  with  advice  and  assistance  from  the  lead  and 
experimental  teams.  Two  scenarios  were  provided  so  that  the  players  could  not  anticipate 
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upcoming  tasks  and  events  in  the  actual  trial  runs  and  preposition  assets  to  accomplish 

them. 


b.         Conduct  of  Training 

Initially,  the  subjects  were  given  a  one-hour  briefing  in  a  classroom  so  they 


understood: 


•  They  were  taking  part  in  an  experiment  (no  experimental  objectives  or 
other  compromising  details  were  divulged). 

•  The  OPORD  and  the  organization  structures  they  were  assigned;  teams 
were  assigned  organizational  structures,  TA  or  NTA.  Teams  were  briefed 
separately  for  experimental  control  purposes.  They  did  not  know  there  was 
any  difference  in  the  organizational  structures  they  were  assigned. 

•  The  DDD-IH  simulation. 

The  purpose  of  this  brief  was  to  give  the  subjects  only  a  general  overview 
of  what  they  would  be  doing  during  the  training  periods  and  the  experiment  trials  and  to 
give  them  some  context  for  the  training  runs.  The  training  runs  were  then  conducted  as 
previously  mentioned,  using  the  training  scenarios  which  contained  no  trigger  events,  but 
in  aggregate,  had  a  requirement  for  all  of  the  subjects  to  use  all  the  assets  within  each 
component.  During  the  training  runs,  four  members  of  the  lead  team  were  present  to 
assist  each  team  of  subjects  in  familiarizing  themselves  with  the  simulation  and 
OPORDER.  The  training  runs  were  also  used  by  the  research  team  members  for  training 
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the  lead  team  observers.  The  training  was  conducted  in  two  one-hour  blocks,  running 
each  team  through  two  different  scenarios.  During  the  first  training  session  the  observers 
and  confederates  provided  instruction  to  the  teams,  stopping  game  time  as  needed.  During 
the  second  hour  of  training,  to  more  closely  prepare  teams  to  deal  with  the  pace  of 
activities  during  the  trials,  game  time  was  not  stopped. 

4.  Experiment  Setup 

The  experiment  was  conducted  during  12  to  22  November  1996.  Observer  and 
confederate  training  was  conducted  to  prepare  the  lead  team-members  for  their  parts  in 
the  experiment  and  re-familiarize  them  with  the  DDD  simulation.  The  observers  were  to 
monitor  team  performance  during  the  trial  runs,  provide  buttonology  assistance  to  the 
players  as  necessary,  control  the  video  recorder,  act  as  DDD-in  simulation  controllers, 
and  take  notes  to  help  evaluate  team  performance  and  communications.  Observers  were 
also  used  during  the  planning  sessions  to  distribute  and  collect  the  data  packages,  keep 
the  teams  focused  on  the  planning  process,  and  run  the  video  recorder.  They  were  also 
available  to  answer  any  questions  the  teams  had  about  the  requirements  and  data 
collection  questionnaires. 

The  confederates  assisted  the  players  in  training  during  the  first  training  run,  then 
acted  as  regular  members  of  the  team. 

The  experimental  trials  consisted  of  three  two-hour  blocks  for  each  of  the  teams. 
Each  team  completed  the  two  training  runs  described  above  during  the  first  time  block. 
The  second  time  block  consisted  of  the  first  trial  run  and  a  "planning  session",  in  which 
the  teams  were  asked  to  evaluate  their  assigned  organizational  structure  (TA  or  NTA)  and 
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propose  any  organization  structural  changes  they  wished  to  make  which  would  improve 
their  ability  to  complete  their  mission  more  effectively.  The  third  time  block  consisted  of 
two  one-hour  planning  sessions.  At  the  start  of  the  hour,  the  teams  were  presented  with 
one  of  the  two  ORDMODs;  a  NEO  which  either  adds  another  mission  and  set  of  tasks  to 
accomplish  in  addition  to  the  current  mission,  with  the  same  resources,  or  a  loss  of 
approximately  one-third  of  the  resources  to  accomplish  the  same  mission.  The  teams 
reviewed  their  ORDMOD  trigger,  then  developed  an  organizational  structure  they  would 
use  to  conduct  the  mission. 

Data  was  collected  during  all  three  runs  of  the  DDD  simulation  by  the  lead  team 
observers  and  the  members  of  the  experimental  team.  The  two  training  runs  in  the  first 
time  block  and  the  data  collection  run  were  each  40  minutes  long.  The  remaining  three 
hours  per  team  were  used  as  planning  sessions  and  survey  and  interview  periods  for  the 
subjects.  These  periods  were  used  by  the  lead  team  and  other  observers  to  collect  data 
from  the  sessions.  At  least  three  members  of  the  lead  team,  in  addition  to  the  lead  team 
confederates,  were  present  at  all  times  during  the  six  hours  of  training,  trials,  and 
planning  sessions  to  monitor  the  subjects,  take  observation  notes  and  collect  data. 

H.         SUMMARY 

How  the  task  design  process  described  in  Chapter  III  was  implemented  for  the 
second  NPS  experiment  is  described  in  this  chapter.  First,  the  experimental  designers 
determined  the  task  structure  dimension  of  interest  and  required  structural  characteristics, 
similar  to  the  tasks  used  in  the  previous  experiment  and  research.  Next,  I  iteratively 
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developed  a  scenario,  using  the  task  structure  description  paradigm  generated  in  Chapter 
EQ,  that  complied  with  the  experimental  designers'  requirements.  This  was  done  within 
the  constraints  of  the  dimensions  of  task  structure  defined  in  Chapter  H  The 
organizational  structures  used  in  the  experiment  were  then  developed  and  checked  to 
verify  structural  differences,  and  OPORDs  and  ORDMODs  were  written.  Finally,  the 
conduct  of  the  experiment  was  described,  including  a  closing  discussion  of  the  scenarios 
and  organizational  structures  that  I  helped  design. 

Chapter  V  will  include  a  brief  overview  of  some  of  the  preliminary  findings  from 
the  data.  Chapter  VI  will  contain  a  discussion  of  the  lessons  learned  from  the  experiment 
with  regard  to  scenario  design,  and  from  the  above  implementation  of  the  scenario  design 
process,  as  well  as  some  of  the  modifications  and  improves  to  the  DDD-DI  simulation. 
Chapter  VII  will  be  a  summary  of  the  issues  discussed  in  this  thesis. 
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V.    PRELIMINARY  FINDINGS 

Preliminary  analysis  of  the  data  from  NPS  experiment  two  provided  some  interesting 
results.  This  is  beyond  the  scope  of  my  thesis,  but  an  overview  of  findings  based  on 
preliminary  data  analysis  by  members  of  the  NPS  research  team  provides  continuity  and 
background  for  future  research  areas  that  I  mention  later  in  Chapter  VII. 

A.         DATA 

Data  was  collected  from  various  sources  and  through  different  methods;  this  would 
provide  a  limited  cross  check  on  data  despite  the  small  sample  size  available.  Data  was 
collected  through  use  of  the  DDD  simulation,  observers  from  the  lead  and  research  teams, 
video  recordings,  and  questionnaires  completed  by  the  players.  The  data  that  was  collected 
consisted  of: 

DDD  log  files  -  Files  from  the  DDD-EQ  simulation  recording  actions  by  each 
DM  during  the  DDD-m  runs. 

Organizational  Charts  (command,  communications)  -  These  are  charts  and 
graphs  developed  by  the  players  during  the  planning  sessions  which  delineated  the  chain  of 
command  and  communication  connectivity  that  would  exist  in  their  proposed  organizational 
structures. 

Asset  ownership,  functional  allocation  -  Developed  by  the  players  during  the 
planning  sessions  to  describe  the  physical  structure  of  their  proposed  organizational  structure. 

Preliminary  task  graphs  -  Developed  by  the  players  during  the  second  and 
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third  planning  sessions  (sessions  with  triggers)  to  explain  their  intentions  and  plans  for 
completing  the  mission  as  modified  by  the  trigger  events. 

Post-planning  questionnaires  -  Completed  by  the  players  at  the  end  of  each 
planning  session  to  solicit  additional  information  from  the  players  about  their  evaluation  of 
the  effectiveness  the  organizational  structures  and  adaptation. 

Observer  data  -  Notes  taken  by  the  observers  evaluating  team  and  player 
performance  during  the  DDD-EQ  runs  and  the  planning  sessions. 

Video  tapes  of  the  DDD  runs  and  planning  sessions  -  Video  recordings  of  the 
DDD-in  runs  and  the  planning  sessions  were  taken.  The  videos  of  the  DDD-1H  runs  provided 
a  copy  of  the  voice  communications.  The  videos  from  the  planning  sessions  provide  the 
research  team  with  an  unobtrusive  method  of  observing  the  thought  processes  of  the  teams 
during  the  planning. 

B.         PRELIMINARY  FINDINGS 

The  following  overview  of  preliminary  findings  is  not  official  and  is  biased  by  my 
personal  thoughts  and  observations  from  the  experiment.  The  final  findings  of  the  entire 
research  team  after  completing  a  detailed  analysis  of  all  the  data  and  modeling  evaluations 
may  be  significantly  different. 

After  the  training  and  trial  runs  on  DDD,  the  teams  were  given  the  opportunity  to 
change  their  organizational  structure  to  perform  the  same  mission.  Teams  were  given  a 
structured  planning  sheet  and  their  initial  organizational  structure  as  the  starting  point. 
Although  no  team  kept  their  initial  organizational  architecture  as  played  on  DDD,  no  team 
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started  from  scratch.  Instead  they  all  "edited"  their  starting  architectures  (TA  or  NTA)  to 
design  their  new  organizational  structure.  All  teams  made  incremental  changes  to 
architectures  that  they  were  apparently  "comfortable"  or  familiar  with. 

•  The  three  traditional  architecture  (TA)  teams  submitted  hierarchical  (3-Level) 
architectures  that  were  essentially  a  "pruned"  traditional  structure,  while  the 
three  nontraditional  architecture  teams  submitted  flat  (2-Level)  architectures 
derived  from  their  starting  architecture.  Although  the  teams  were  instructed  to 
design  a  six  node  architecture,  after  trigger  two,  four  of  the  six  teams  wanted 
organizations  with  less  than  six  nodes. 

In  order  to  determine  if  these  are  "results"  or  just  artifacts,  a  more  complete 
analysis  is  in  progress. 

•  While  both  organizations  had  a  similar  workload  at  the  DM  0  level,  the 
traditional  architecture  generally  outperformed  the  nontraditional  architecture 
on  mission  performance  subtasks,  with  "mission"  scores  averaging  96% 
versus  85.3%  even  though  the  nontraditional  architecture  required  (and 
showed)  fewer  inter-DM  coordinations  on  mission  performance  subtasks. 

•  The  traditional  and  nontraditional  architectures  performed  about  the  same 
overall  on  defend  and  encounter  tasks.  These  invariably  were  done  by  a  single 
DM  in  both  organizations. 

•  The  traditional  architecture  was  better  at  suppressing  ground  threats  while  the 
nontraditional  architecture  appears  to  have  been  better  at  ASW  and  ASUW 
defense. 
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•  There  is  a  strong  linear  correlation  (R  =  0.95)  between  rated  teamwork  and  the 
computer  generated  performance  score,  but  I  do  not  know  if  this  is  a  rater 
phenomenon  or  an  indicator  of  "better"  teams?  (Did  the  observers  note  the 
higher  performance  scores  and  then  rate  the  team  work  higher?) 

•  For  some  tasks,  the  rated  performance  does  not  agree  with  actual  performance 
as  recorded  by  the  DDD  simulation.  There  are  several  instances  where  the 
observers  consistently  rated  the  TA  teams  as  "better"  in  performing  specific 
tasks  yet  DDD  log  files  show  there  was  no  significant  difference  in  TA  and 
NT  A  performance  scores  for  these  tasks.  This  may  indicate  some  amount  of 
the  "halo  effect"  influencing  an  observer's  rating  of  a  team. 

Although  the  dimensions  of  task  structure  and  the  task  structure  diagrams  based  on 
the  scenario  for  the  trial  runs  were  identical  or  nearly  so,  the  resource  allocation  within  the 
assigned  organizational  structures  (TA  and  NTA)  was  significantly  different.  This 
fundamental  difference  in  the  resource  allocation  assigned  to  the  TA  and  NTA  organizational 
structures  required,  in  my  opinion,  a  far  different  mind  set  on  the  part  of  the  players  in  each 
architecture  for  the  conduct  of  the  overall  mission,  and  negatively  affected  the  nontraditional 
architecture  players'  initial  performance.  This  was  apparent  in  the  much  steeper  (larger  rate 
of  change  in  performance  scores  from  one  trial  to  the  next)  learning  curve  exhibited  by  these 
teams.  It  is  my  belief  that,  the  human  "comfort  level"  or  familiarity  with  the 
situation/organization  significantly  influences  the  efficiency  and  effectiveness  of  joint 
operations.  This  problem  is  correctable  and  must  be  factored  into  joint  training  and  doctrine 
for  joint  operations  and  experiments. 
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1.  Traditional  Architecture  (NPS) 

All  3  teams  kept  the  same  (3-tier)  structure(s)  except  for  attempts  to  tie  CAS  more 
tightly  to  the  rifle  companies  (DM  4  and  DM  5)  (e.g.,  assign  CAS  to  DM  1  and  DM  3,  or 
establish  separate  cells  in  DM  2  to  coordinate  with  DM  4  and  DM  5). 

The  traditional  architecture  teams  felt  that  the  allocation  of  resources  for  their  initial 
organization  was  more  "realistic"  than  the  nontraditional  teams.  (Perhaps  what  we  are  used  to 
is  considered  more  "realistic".) 

2.  Nontraditional  Architecture    (Model-Derived) 

Although  all  three  teams  selected  a  flat  (2-tier)  structure  with  some  reallocation  of 
assets,  there  was  no  consistent  pattern  across  teams  to  the  changes  in  asset  allocation  in  the 
new  architectures  (perhaps  because  of  a  lack  of  experience,  training,  and  doctrine  to  guide 
them,  they  were  taking  their  "best  shot"  at  improving  their  performance).  Two  of  the  teams 
allocated  CAS  to  node  DM  2  which  was  underutilized  in  the  original  nontraditional 
architecture. 

C.         CONCLUSIONS 

An  in-depth  analysis  of  the  data  still  needs  to  be  completed.  The  initial  findings  that  I 
presented  in  this  chapter  may  not  endure  the  full  analysis  by  the  A2C2  team.  However  the 
preliminary  analysis  of  the  data  by  the  NPS  research  team  indicates  interesting  results 
concerning  human  influence  on  organizational  adaptation  are  possible. 
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VI.  LESSONS  LEARNED  AND  MODIFICATIONS  AND 
IMPROVEMENTS  TO  THE  DDD-III  SIMULATION 


Upon  completion  of  NPS  experiment  two,  the  observations  of  the  A2C2  researchers 
and  lead  team  members  made  it  clear  that  there  were  ways  to  improve  the  design  of 
experiment,  task  design  process,  and  the  data  collection  methods  for  future  experiments.  I 
focus  here  on  the  items  of  interest  in  my  thesis,  the  task  structure  and  scenario  development 
and  enrichment  process. 

A.    LESSONS  LEARNED  FROM  THE  SCENARIO  DEVELOPMENT  PROCESS 

Following  the  completion  of  NPS  experiment  one,  the  experiment  team  received 
complaints  from  the  players  about  the  lack  of  realism  in  the  scenario.  Significant  efforts  went 
into  improving  the  simulation  and  the  scenario  to  correct  this  shortcoming,  but  there  is  still 
room  for  continued  improvement. 

1.         Tradeoff  Between  Realism  and  Coordination 
There  are  three  main  areas  where  complaints  concerning  realism  in  the  second 
experiment  occurred;  limited  capability  of  the  assets,  rigid  task  performance  sequencing,  and 
"non-thinking"  troops  or  the  lack  of  "smart"  forces.  I  will  discuss  these  in  more  detail  in  the 
following  subsections. 

a.  Limited  Capability  Assets 

Based  on  the  criticism  concerning  realism  received  from  subjects  in  NPS 
experiment  one,  many  changes  were  made  to  make  NPS  experiment  two  more  realistic. 
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However,  criticisms  concerning  the  scenario's  lack  of  realism  were  still  received  from  the 
subjects  of  experiment  two  as  well,  but  to  a  lesser  extent.  Realism  tradeoffs  is  a  complex 
issue  that  I  addressed  during  the  design  and  development  of  the  scenario  for  experiment  two. 
There  is  a  balancing  act  between  realism  and  control  of  experiment  issues.  To  induce  DMs  to 
coordinate  resources  to  complete  complex  tasks  with  other  DMs,  scenario  events  were 
introduced  in  a  consistent,  reproducible  manner.  The  scenario  forced  the  coordinated  use  of 
multiple  assets  owned  by  multiple  DMs  to  perform  certain  tasks.  This  resulted  in  some 
unrealistic  restrictions  since  military  platforms  can  usually  conduct  more  than  one 
operation/evolution  at  a  time  and  are  capable  of  engaging  more  than  one  target  at  a  time.  A 
scenario  design  that  allowed  the  assets  to  more  accurately  reflect  the  real  world  would  have 
allowed  the  teams  to  create  their  own  task  structures  and  avoid  entirely  the  coordination 
events  that  were  the  focus  of  the  experiment.  Enhancements  to  DDD  which  will  enable 
multiple  target  engagements  by  some  of  the  platforms  are  being  investigated  for  use  in  future 
experiments. 

b.  Hard  Prerequisites 

Designing  the  implementation  of  the  scenario  in  the  simulation  so  that  certain 
activities  must  be  performed  before  others  (hard  prerequisites)  is  helpful  for  ensuring  that  a 
team  follows  a  desired  task  structure.  Like  the  design  of  limited  capability  assets, 
development  of  hard  prerequisites  impacts  the  level  of  realism.  The  value  of  strictly 
following  a  desired  task  structure  for  experiment  control  purposes  must  be  balanced  against 
the  value  of  allowing  a  team  to  make  mistakes  or  solve  problems  on  its  own.  This  issue  is 
also  intertwined  with  DDD  training,  operator  training,  doctrine  and  experience  level,  and  the 
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TA  and  NTA  organizational  architectures.  Since  the  focus  of  this  project  is  adaptation  of 
organizations  rather  than  innovative  problem  solving,  hard  prerequisites  work  to  our 
advantage  and  will  remain  a  part  of  the  experimental  design. 
c.  "Smart"  Forces 

In  the  current  version  of  DDD,  forces  will  continue  into  a  hazard  even  after  it 
has  been  identified  unless  the  DM  who  owns  the  asset  halts  it.  No  message  or  warning  is 
given  to  the  DM,  so  if  he  isn't  focused  on  that  area  or  asset,  he  won't  recognize  the  hazard 
(task),  and  performance  points  are  lost.  An  enhancement  to  DDD  that  causes  forces  to  stop 
when  a  hazard  is  encountered  and  send  an  alert  message  to  the  DM  is  being  investigated. 
This  may  prove  beneficial  to  the  experimenters  in  several  ways  besides  increasing  realism. 
Fewer  assets  (tasks)  will  be  "lost"  due  to  inadvertent  encounters,  and  the  communications 
"noise"  level  (load  level)  will  increase. 

2.    Task  Spawning 

The  use  of  task  spawning,  where  completion  of  a  specific  event  or  action  triggers 
another  task  or  event,  allowed  an  additional  degree  of  realism  in  the  DDD  simulation.  The 
actions  of  the  DMs  are  used  to  activate  a  task  rather  than  activating  tasks  simply  based  on 
game  time.  For  example,  in  the  second  NPS  experiment,  the  attack  on  the  hill  triggered 
enemy  air  attacks.  In  the  first  NPS  experiment  the  background  tasks  and  obstacles  appeared 
based  on  game  time,  whether  the  friendly  forces  had  initiated  any  actions  or  not. 
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B.         LESSONS  LEARNED  FROM  CONDUCT  OF  THE  EXPERIMENT 

During  the  conduct  of  the  experiment  and  initial  analysis  of  the  data,  it  was  apparent 
that  there  were  several  areas  where  the  design  and  implementation  of  the  experiment  and  data 
collection  methods  could  be  improved. 

1.    Use  of  Confederates 

The  manner  in  which  the  use  of  confederates  in  the  two  organizational  structures  was 
implemented  was  the  source  of  some  difficulty.  First,  there  were  only  three  confederates  so 
they  be  alternated  between  teams  and  positions.  While  the  same  confederates  remained  paired 
with  a  team,  they  didn't  remain  paired  with  each  other  or  always  play  the  same  position.  This 
resulted  in  some  differences  in  the  interactions  between  the  DMs  as  a  result  of  personality 
issues.  The  use  of  only  three  confederates  was  based  on  limited  people  in  the  lead  team  and 
scheduling  constraints.  The  design  team  had  felt  that  it  would  not  have  any  significant  impact 
on  the  results,  but  post-experiment  analysis  of  the  data  revealed  that  some  of  the  confederates 
had  significantly  more  input  during  the  scenario  than  others.  If  confederates  are  used  in  future 
experiments,  I  recommend  keeping  them  paired  with  each  other  and  filling  the  same  DM 
positions  each  time  to  control  individual  DM  effects  throughout  the  experiment.  If  a  pair  of 
confederates  is  treated  as  a  unit  "personality",  using  four  confederates  would  allow  two 
confederate  pairs  to  be  formed  instead  of  the  three  confederate  pairs  required  using  only  three 
confederates. 
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2.  Increase  Time  Pressure 

Additional  time  pressure  (workload)  would  have  improved  the  experiment.  Several  of 
the  teams  in  experiment  two  operated  under  a  reasonable  amount  of  time  pressure.  The  other 
teams,  composed  of  more  operationally  proficient  members,  appeared  to  work  under 
relatively  low  time  pressure  while  accomplishing  the  same  tasks.  The  more  operationally 
proficient  teams  tended  to  score  well  based  on  performance  measures  independent  of 
workload  (Noted  in  scores  during  training  runs  and  experiment  run),  making  it  difficult  to 
find  any  difference  between  the  time  pressure  (workload)  factor  levels.  A  solution  is  to 
increase  time  pressure  by  increasing  the  workload  rate.  This  is  achieved  by  increasing  the 
number  of  activities  (subtasks)  within  the  scenario  or  increasing  the  quantity  and  complexity 
of  the  coordination  events.  Increasing  the  clock  time  rate  of  the  simulation  is  not  a  good 
option,  when  the  clock  time  is  increased,  the  screen  display  graphics  do  not  keep  pace  with 
the  objects'  actual  positions  in  the  data  files  and  it  becomes  difficult  to  "tag"  moving  objects 
for  attack  or  identification. 

3.  Increased  Number  of  Coordination  Events 

Increasing  the  number  of  coordination  events  by  enriching  the  scenario  with  other 
assets,  tasks,  and  background  events  results  in  more  data  points  for  analysis.  This  must  be 
accomplished  in  such  a  way  that  the  overall  run  time  of  the  scenario  is  not  significantly 
increased  (40  minutes).  If  scenario  runtime  becomes  too  long,  the  number  of  replications 
(sample  size)  is  reduced  due  to  the  fixed,  limited  time  the  players  have  available  for  the 
experiment. 
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4.    Team  Formation 

The  varied  operational  experience  level  of  the  officers  performing  as  subjects  in  NPS 
experiments  continues  to  be  a  challenge.  Officers  with  significant  operational  experience 
more  easily  adapted  to  the  scenario  and  tended  to  perform  better  than  their  classmates  with 
less  experience.  Performance  variance  due  to  experience  made  it  difficult  to  attain  a 
reasonably  constant  level  of  difficulty  across  teams  and  individuals,  but  just  the  opposite  is 
desired  for  control  purposes  (keep  everything  as  constant  as  possible  across  the  trials  by 
design  of  the  experiment  and  counterbalancing  to  neutralize  differences  between  teams).  This 
factor  may  become  more  pronounced  as  A2C2  experiments  progress  toward  more  realism 
with  higher  command  levels  and  more  senior  players.  This  must  be  addressed  as  we  continue 
to  gather  additional  knowledge  of  adaptive  command  and  control  architectures  in  a  joint 
operational-level  context.  In  real  world  operations,  this  problem  would  hopefully  be 
eliminated  or  mitigated  by  training  and  doctrine  as  well  as  by  competent  staff  members  to 
provide  advice  and  recommendations. 

Officers  who  were  operationally  experienced,  but  played  a  role  in  the  experiment 
outside  of  their  area  of  expertise,  did  not  tend  to  function  as  well  as  their  subordinates  who 
were  in  their  area  of  expertise. 

While  readily  apparent  in  the  small  subject  pool  used  in  the  A2C2  experiment  two,  it 
may  contribute  to  the  realism  of  the  results.  All  the  officers  assigned  to  a  task  force  will  not 
have  the  same  level  of  expertise  and  capability.  The  organization  must  determine  the  best  use 
the  assets  that  are  allocated  to  it,  human  and  equipment. 
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5.    Data  Collection  Methods 

Data  collected  in  the  planning  sessions  tended  to  be  more  qualitative  or  subjective 
than  quantitative;  this  made  analysis  of  the  data  more  challenging.  Frequently  the  analysts 
made  judgement  calls  based  on  the  subjects'  statements. 

More  detailed  piloting  and  testing  of  the  data  collection  forms  and  questionnaires  is 
required.  A  thorough  review  by  persons  uninvolved  with  the  original  draft  of  these 
documents  would  be  very  helpful.  Questions  that  I  thought  were  straightforward  and  obvious 
were  actually  ambiguous  in  many  cases  depending  on  the  respondent's  level  in  the  command 
structure. 

a.         Data  incomplete  and/or  inconsistent 

The  subjects  and  observers  did  not  have  sufficient  time  to  complete  an 
analysis  and  planning  session  and  fill  out  the  required  forms.  I  thought  the  essay  type 
questions  used  as  part  of  the  data  collection  forms  would  yield  the  most  data,  providing  more 
insight  into  the  thought  processes  the  players  used  to  arrive  at  their  answers,  and  allowing  the 
widest  range  of  answers.  Due  to  the  limited  time  available  for  planning,  reaching  a  consensus 
among  the  team  members,  and  filling  out  the  forms  resulted  in  answers  that  were  incomplete, 
hard  to  read,  and  inconsistent  within  a  team.  Post-experiment  analysis  required  "experts"  to 
fill  in  gaps  or  interpret  the  answers.  In  many  cases  it  was  necessary  to  go  back  to  the  video 
tapes  of  the  planning  sessions  to  resolve  ambiguities  and  inconsistencies  in  the  written 
answers.  Use  of  multiple  choice  questionaires,  checklists,  and  spreadsheets  to  obtain  asset- 
to-DM  and  DM-to-task  allocations  may  be  helpful  to  mitigate  these  problems  in  the  future. 
Other  recommendations  to  improve  the  usability  of  the  data  would  be  to  immediately  follow- 
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up  planning  sessions  with  semi-structured  interviews  or  to  have  the  designated  CJTF  brief 
and  defend  the  (re)organization  to  the  Commander-in-Chief.  Significantly  more  time  is 
required  to  extract  and  analyze  the  data  from  oral  interviews,  and  the  interviews  would 
require  additional  time  from  the  subjects,  either  reducing  the  time  available  for  DDD  runs 
and  planning  sessions  or  increasing  the  amount  of  time  per  team  to  complete  their  trial. 
C.        SUMMARY 

While  it  is  desirable  to  approach  the  operational  environment  as  closely  as  possible 
during  the  experiments,  this  must  be  balanced  against  the  need  for  control  of  the  experiment. 
While  it  may  be  necessary  to  introduced  some  artificialities  into  small  scale  experiments  to 
ensure  the  phenomena  that  are  being  investigated  occur,  it  is  imperative  that  the  artificialities 
be  introduced/implemented  in  a  way  that  does  not  alter  the  phenomena  themselves. 

Chapter  VII  will  be  a  summation  of  the  paper  and  will  present  some  short  term 
research  areas  for  future  experiments. 
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VII.    THESIS  SUMMARY  AND  FUTURE  RESEARCH  PLANS 

The  A2C2  project  is  an  ongoing  research  effort,  building  on  the  data  collected  and  the 
lessons  learned  in  each  experimental  cycle.  The  preliminary  findings  of  the  data  from  NPS 
experiment  two  have  piqued  the  interest  of  ONR  and  the  research  teams  in  several  additional 
areas.  I  summarize  my  thesis,  then  list  some  of  the  short  term  future  research  areas  for  follow 
on  experiments. 

A.         SUMMARY  OF  THESIS 

This  thesis  was  conducted  as  a  part  of  the  Adaptive  Architectures  for  Command  and 
Control  (A2C2)  research  project,  which  seeks  to  explore  how  teams  adapt  in  reaction  to 
changes  in  resource  availability  and  mission  caused  by  internal  and  external  triggers.  The 
project's  second  NPS  experiment  involved  studying  interaction  between  resources  and  task 
structures  and  organizational  structure  and  the  resulting  adaptation  of  organizational 
structure. 

This  thesis  describes  a  process  for  developing  military  operational  scenarios  within  a 
task  structure  context.  First,  I  conducted  a  review  of  Michael  Berigan's  work  [Berigan,  1996] 
which  defines  the  dimensions  of  task  structure  applicable  to  this  project,  develops  a  grading 
scale  for  each  dimension,  gives  examples  of  the  dimensions  and  grades  each  example,  and 
describes  how  changes  in  one  dimension  might  affect  other  dimensions.  Then  a  method  for 
developing  scenarios  in  accordance  with  a  predetermined  structure  and  visualizing  tasks  is 
described,  including  a  task  structure  diagram  and  a  description  of  a  task  design  process  using 
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the  diagram  and  the  dimensions  previously  delineated.  I  then  apply  the  task  design  process  by 
developing  scenarios  and  organization  structures  for  the  experiment  that  allow  an  evaluation 
of  the  interactions  between  task/mission  and  organizational  structure  across  one  dimension  of 
task  structure,  coordination  requirements.  Finally,  a  description  of  the  experiment  is  given, 
including  discussion  of  the  scenarios  and  organizational  structures,  preliminary  findings,  and 
lessons  learned  from  the  experiment  with  regard  to  scenario  design. 

B.         FUTURE  RESEARCH  AREAS 

Research  efforts  will  continue  to  focus  on  the  concept  of  adaptation.  The  first  phase 
of  the  A2C2  project  developed  joint  C2  scenarios,  investigated  the  mapping  of  tasks  onto 
architectures,  and  studied  structural  and  architectural  variables  and  their  effects  on 
organizational  performance  and  began  looking  at  adaptation.  The  next  step  in  the  A2C2 
research  effort  will  focus  on  the  investigation,  both  theoretically  and  experimentally,  of  the 
variable  of  adaptation.  The  next  phase  of  A2C2  research  will  focus  on: 

•  Identifying  and  understanding  the  decision  of  organizations  to  adapt  their 
organizational  structure. 

•  Understanding  the  consequences  of  adaptation  in  terms  of  organizational 
processes  and  performance. 

An  area  of  high  interest  is  the  concept  of  incremental  organizational  changes  as 
opposed  to  sudden  drastic  switches  in  structure.  Several  sources  in  the  organizational  theory 
literature  argue  that  organizations  resist  radical  changes  to  their  structure  even  when  changes 
in  the  environment  warrant  a  drastic  change.  This  is  particularly  true  after  having  performed 
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well  under  a  given  architecture.  In  other  words,  human  organizations  may  prefer  familiarity 
or  robustness  of  performance  across  a  wide  range  of  tasks  and  resources  to  optimality  of  an 
organizational  structure  to  one  specific  mission. 

For  a  more  detailed  look  at  proposed  research,  see  Adaptive  Architectures  for 
Command  and  Control  (A2C2)  Research  Plans  (Version  1.1),  June  1997,  by  Daniel  Serfaty 
of  Aptima,  Inc. 
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APPENDIX  A.  OPORDER's,  ORDMOD's,  AND  QUICK  REFERENCE 

SHEETS 

Appendix  A  contains  the  OPORDER's  for  the  TA  and  NTA  organizations,  the 
ORDMOD's  for  the  noncombatant  evacuation  operation  (NEO)  vignettes  (one  adding  tasks  to 
the  mission,  the  other  taking  assets  away  from  the  organization),  and  the  quick  reference  sheets 
which  were  provided  to  the  players. 

Traditional  Architecture  OPORDER    106 

Nontraditional  Architecture  OPORDER 113 

ORDMOD  (add  NEO)    120 

ORDMOD  (remove  assets)  123 

Quick  Reference  Sheets    126 

DDD  Tutorials     128 
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IMMEDIATE 


TA 


FROM: 


USCINCMED  NAPLES  IT 
CJTF  FOUR 


TO: 


CJCS  WASHINGTON  DC 
USCINCCENT  MACDILL  AFB  FL 
USCINCLANT  NORFOLK  VA 
USCINCEUR  VAIHINGEN  GE 
CINCFOR  FT  MCPHERSON  GA 
USCINCPAC  HONOLULU  HI 
USCINCTRANS  SCOTT  AFB  IL 
USCINCSTRAT  OFFUTT  AFB  NE 
COMMARFORPAC  HONOLULU  HI 
CINCPACFLT  HONOLULU  HI 
JTFFOUR 


INFO: 


WHITEHOUSE  SITUATION  ROOM  WASHINGTON  DC 

SECSTATE  WASHINGTON  DC 

SECDEF  WASHINGTON  DC 

CSA  WASHINGTON  DC 

CMC  WASHINGTON  DC 

CNO  WASHINGTON  DC 


DISTR: 


CINC/DCINC/CCJ1/CCJ2/CCJ3/CCJ4/CCJ5/CCJ6 


FOR  OFFICIAL  USE  ONLY 

OPER/THUNDER  SPEAR// 

MSGED/ORDER/USCINCCENT// 

AMPN/SPECIAL  HANDLING  INSTRUCTIONS 

REF/A/ORDER/CJCS/01 1742Z  NOV  96// 

REF/B/ORDER/CJCS/041 142Z  NOV  96// 

NARR/JT  STRAT  CAP  PLN  (FY  96),  CJCS  ALERT  ORDER// 

ORDTYP/OPORD/USCINCCENT  11-96// 

MAP/10 15/TUNSIA// 

MAP/1020/Yang// 

NARR/SCALE  1:100,000// 

TIMEZONE/Z// 

HEADING/TASK  ORGANIZATION// 
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UNITS 


/UNITDES 


/UNITLOC 


/CMNTS 


/USCINCLANT 

/USCINCEUR 

/CINCFOR 

/USCINCPAC 

/USCINCTRANS 

/USCINCSTRAT 

/COMMARFORPAC 

/CINCPACFLT 

/HQ  USMEDCOM  FWD 

/HQ  USMEDAF  (MINUS) 

/HQ  USNAVMED  (MINUS) 

/SUPPORTING  FORCES 

/COMSUPNAVFOR 

/MPS// 


/NORFOLK  VA 
/VAIHINGEN  GE 
/FT  MCPHERSON  GA 
/HONOLULU  HI 
/SCOTT  AFB  IL 

/OFFUTTAFBNE 
/HONOLULU  HI 

/HONOLULU  HI 


II  TAC  ARLFT  SQ 
/6KC-10 
/2RC-135 
/1MEB 

/(JTF  4) 


GENTEXT/SITUATION 

1 .  (FOUO)  Yang  has  attacked  the  friendly  nation  of  Ying.  Attacking  forces  have  succeeded  in  seizing 
Yingian  port  of  Plethora.  Yingian  government  has  requested  U.S.  assistance  in  taking  back  port  of 
Plethora  and  driving  Yangian  forces  from  Ying. 

A.  (FOUO)  ENEMY  FORCES 

1.   (FOUO)  See  current  SITREP  and  DIN.  Port  of  Plethora  protected  by 
obstructions,  mines,  obstacles,  and  the  presence  of  hidden  enemy  among  the  port  facility  buildings.  Two 
beaches  approx.  5  miles  south  of  the  port  may  be  suitable  for  amphibious  assault.  Northernmost 
beach  (designated  "Red  Beach")  has  road  leading  to  the  port.  Southernmost  beach  (designated  "Blue 
Beach")  has  a  road  leading  to  the  airfield.  Waterborne  approaches  to  the  beaches  are  possibly  mined. 
Commanding  terrain  to  north  of  Red  Beach  believed  occupied  by  enemy  Heavy  Mortar  Platoon  with 
a  platoon  of  Infantry  for  security.  This  terrain  dominates  both  Red  Beach  and  the  port.  Seizure  and 
retention  of  this  dominant  terrain  should  be  considered  essential  for  successful  attack  on  Red  Beach 
and  port. 

(2)  (FOUO)  Believed  to  be  at  port,  but  hidden  from  view,  is  company-sized  armored 
counterattack  force  that  could  move  toward  Red  Beach  in  response  to  any  amphibious  assault. 
Similar  counterattack  force  may  exist  at  airfield,  which  is  located  about  5  miles  inland  from  the  Blue 
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Beach.  These  counterattack  forces  could  inflict  serious  damage  if  not  interdicted  before  they  reach 
either  beach.  Off-road  terrain  between  beach,  port,  airfield,  and  commanding  terrain  is  swampy  and 
treacherous;  and  is  unsuitable  for  travel.  Thus,  all  travel  must  be  on  the  two  roads.  It  is  believed  that 
one  or  both  of  the  roads  will  be  mined.  Locations  of  any  minefields  are  currently  unknown.  Port, 
airfield,  both  roads,  both  beaches,  and  commanding  terrain  are  located  within  range  of  artillery 
strong-points.  Northernmost  strong-point  can  range  Red  Beach  and  port.  Southernmost  strong-point 
can  range  both  Blue  Beach  and  airfield.  Artillery  pieces  are  housed  in  reinforced  concrete  bunkers, 
with  ammunition  stored  in  deep  underground  bunkers.  It  is  unlikely  that  even  concentrated  air 
attacks  will  completely  disable  the  artillery  strong-points.  Enemy  can  be  expected  to  wheel  out 
artillery  pieces  (from  8  to  24  at  a  time),  set  up,  sight  in,  and  fire  within  5  minutes.  If  friendly  forces 
can  get  effective  NSFS  on  target  in  less  than  5  minutes,  the  enemy  will  most  probably  wheel  their 
artillery  pieces  back  into  bunkers  and  wait  until  another  time. 

(3)  (FOUO)  Enemy  also  has  several  Frog  Missile  Launchers  known  to  be  capable  of  carrying 
chemical  munitions.  Frogs  believed  to  be  hidden  in  the  vicinity  of  both  artillery  strong-points.  They 
can  emerge  from  covered  positions,  prepare  warheads,  and  fire  missiles  within  10  minutes.  Past 
experience  has  shown  that  Frog  crews  are  more  stalwart  than  artillery  crews.  They  will  continue  to 
prepare  and  launch  their  missiles  even  if  they  are  being  suppressed  by  NSFS  or  artillery. 

(4)  (FOUO)  Submarine  threat  is  considerable.  Enemy  has  at  least  one  Alfa-Class  submarine 
known  to  be  in  the  area,  and  possibly  more. 

(5)  (FOUO)  Enemy  possess  HIND  Helicopters,  which  have  demonstrated  the  capability  to 
launch  anti-ship  missiles.  The  DDG,  CG  and  CV  possess  capabilities  to  counter  these  helicopters. 

2.   FOUO)  The  enemy  has  significant  air  strike  capability,  and  can  launch 
anti-ship  missiles  from  most  of  its  strike  aircraft. 

(7)  (FOUO)  The  enemy's  Special  Forces  also  possess  numerous  fast  patrol  boats,  that  can  either 
fire  very  potent  Russian  torpedoes  or  be  loaded  with  explosives  for  suicide  missions. 

(8)  (FOUO)  There  are  Silkworm  threats  throughout  the  area.  The  Silkworm  missiles  are  placed 
in  residential  neighborhoods  because  they  know  U.S.  will  be  reluctant  to  target  residential  areas. 
Accordingly,  if  U.S.  warships  want  to  target  a  Silkworm  launcher,  they  must  first  get  visual 
confirmation  of  its  presence,  using  theater  RECON  (TARPS)  assets,  and  any  strike  must  use 
precision  guided  munitions. 

B.  (FOUO)  FRIENDLY  FORCES.    JTF  4  will  be  comprised  primarily  of  assets  organic  to 
Mediterranean  Command  (MEDCOM).  A  theater-level  JFACC  and  other  friendly  forces  are 
operating  against  the  enemy  in  Ying,  but  not  in  concert  with  the  JTF. 
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3.  (FOUO)  JTF  4  will  consist  of  one  RECON  (TARPS),  and  subordinate  units 

(4.1,4.2,4.3,4.1.1,4.3.1). 

4.  (FOUO)  JTG  4.1  will  consist  of  one  DDG,  one  LPD,  two  Cobra  Sections, 
one  Huey  MEDEVAC,  and  one  MH-53  MCM. 

(3)  (FOUO)  JTG  4.2  will  consist  of  one  CV,  one  CG,  two  FFG's,  eight  Fighter  Sections,  and 
eight  CAS  Sections. 

5.  (FOUO)  JTG  4.3  will  consist  of  one  DDG,  one  LHA,  two  Cobra  Sections, 
one  Huey  MEDEVAC,  and  one  MH-53  MCM. 

(5)  (FOUO)  JTU  4.1.1  will  consist  of  three  Rifle  Companies,  one  Engineer  Platoon,  one  Stinger 
Detachment,  two  AAAV  Platoons,  and  one  MV22. 

(6)  (FOUO)  JTU  4.3.1  will  consist  of  three  Rifle  Companies,  one  Engineer  Platoon,  one  Stinger 
Detachment,  one  AAAV  Platoon,  and  two  MV22s. 

(7)  (FOUO)  Continuous  coverage  by  RECON  (TARPS)  will  be  maintained  in  general  support 
of  theater  CINC.  May  be  tasked  with  any  immediate  imagery  requirements.// 

GENTEXT/MISSION/ 

2.  (FOUO)  On  order,  JTF  4  ground  forces  will  seize  and  defend  Yingian  Port  of  Plethora,  to  allow 

introduction  of  follow  on  forces  in  support  of  Yingian  government  troops.  Sea-based  forces  will 
support  amphibious  assault  with  CAS,  naval  gunfire,  and  air  defense  assets.// 

GENTEXT/EXECUTION/ 

3.  (FOUO)  CONCEPT  OF  OPERATIONS 

A.  GROUND.  Each  GCE  will  simultaneously  land  one  AAAV-Mounted  Platoon  on  respective 
beach.  JTU  4.3.1  will  simultaneously  take  commanding  terrain  with  one  MV22.  Once  BOTH 
beaches  and  commanding  terrain  are  secure,  the  two  AAAV-Mounted  Platoons  will  proceed  down 
the  roads  from  their  respective  beaches,  clearing  minefields  with  Engineer  Platoons,  killing 
counterattack  forces  with  Cobra  Sections,  and  conducting  MEDEVACS  as  necessary.    Once  the 
roads  have  been  cleared,  the  AAAV-Mounted  Platoons  will  take  the  port  and  airfield.  JTU  4.1.1s 
AAAV-Mounted  Platoon  will  be  assisted  in  its  attack  of  the  airfield  by  a  MV22.  It  is  important  that 
once  the  AAAV-Mounted  Platoons  land  on  the  beach,  the  airfield  and  port  be  taken  as  quickly  as 
possible,  before  the  enemy  has  a  chance  to  organize  his  defense  and  send  reinforcements.  We  would 
like  to  conduct  the  final  assaults  on  the  airfield  and  port  simultaneously,  in  order  to  present  the 
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enemy  commander  with  the  most  confusing,  dilemma-filled  environment  possible.  However,  if  one 
attack  must  occur  before  the  other,  the  airfield  has  the  priority. 

B.  MARITIME.  Due  to  hydrographic  limitations,  the  DDG's  and  the  CV  will  have  to  be 
significantly  separated  during  the  operation,  enough  to  preclude  them  from  being  under  a  Joint  Air 
Defense  umbrella  provided  by  the  CG.  Thus,  the  CG  will  remain  with  the  CV,  but  will  position  itself 
so  that  it  can  rapidly  move  from  the  CV  to  the  DDG's  if  that  becomes  necessary.  Additionally,  the 
two  DDG's  are  inshore,  providing  NSFS  support,  while  the  FFG's  are  the  primary  ASW  platform  for 
the  CV.  The  FFG's  performing  ASW  will,  like  the  CG,  position  themselves  so  that  they  can  quickly 
move  to  support  the  DDG's  if  that  is  necessary. 

4.  (FOUO)  TASK  ASSIGNMENT  JTU  4.3. 1.  On  order  from  JTF  4,  land  one  AAAV-Mounted  Platoon 

on  Red  Beach.  Simultaneously  seize  commanding  terrain  to  the  north  of  Red  Beach  with  one  MV22. 
Once  the  beach  and  commanding  terrain  are  secure,  attack  along  the  road  from  the  beach  to  the  port, 
clearing  minefields  with  Engineer  Platoon,  killing  counterattack  forces  with  Cobras  and  conducting 
MEDEVACS  as  necessary.  Once  the  roads  have  been  cleared,  attack  the  port  with  the  AAAV- 
Mounted  Platoon. 

5.  (FOUO)  TASK  ASSIGNMENT  JTU  4.1.1.  On  order  from  JTF  4,  land  one  AAAV-Mounted  Platoon 

on  Blue  Beach.  Once  the  beach  is  secure,  attack  along  the  road  from  beach  to  airfield  with  AAAV- 
Mounted  Platoon,  clearing  minefields  with  Engineer  Platoon,  killing  counterattack  forces  with 
Cobras,  and  conducting  MEDEVACS  as  necessary. 

6.  (FOUO)  TASK  ASSIGNMENT  JTG  4.2.  Keep  two  elements  of  CAS  on  standby  at  all  times:  one  to 

be  used  against  Frog  or  Scuds,  and  the  other  to  be  used  against  Silkworms.  CV  will  provide  3 
sections  of  air  defense  aircraft,  with  one  CAP  station  over  the  CV  and  the  others  over  the  DDG's. 
FFG's  will  provide  ASW. 

7.  (FOUO)  TASK  ASSIGNMENT  JTG  4.1  and  JTG  4.3.  On  order  from  JTF  4,  units  will  clear  mines 

from  the  beaches.  Units  will  launch  Marines  for  assault  on  Red  and  Blue  Beaches.  DDG's  will 
suppress  artillery  strong-points  ashore  when  requested  to  do  so.  Units  will  provide  all  MEDEVAC 
support  and  all  Cobra  support. 

8.  (FOUO)  COORDINATING  INSTRUCTIONS. 

A..  (FOUO)  This  order  effective  for  planning  upon  receipt  and  execution  on  order. 

B.  (FOUO)  Dirlauth  for  planning  and  operations  with  Info  CJCS  and  CINCMED. 

C.  (FOUO)  ROE  will  be  per  CINCMED  OPLAN  1234. 
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D.  (FOUO)    If  the  airfield  attack  is  held  up  for  any  reason,  the  port  attack  will  be 

delayed  to  retain  the  synergism  of  concurrent  attacks.  If  the  port  attack  is  held  up,  the  airfield  attack  will 
go  forward. 

E.  (FOUO)  JTU  4.1.1's  attack  on  the  airfield  has  priority,  because  buildup  of  forces 
can  be  most  quickly  and  effectively  achieved  through  air  transport. 

F.  (FOUO)  Enemy  patrol  boats  or  other  surface  craft  will  be  engaged  by  the  DDG's. 

G.  (FOUO)    If  both  the  DDG  and  the  CV  are  threatened  by  the  enemy,  the  DDG  has 
priority  of  support  against  submarine  threats,  fixed-wing  air  threats,  and  patrol  boats. 

H.  (FOUO)  If  there  is  a  threat  of  an  air  attack  against  the  DDG,  the  DDG  will  be  protected  by  the  CG  or 
a  CAP. 

I.  (FOUO)  The  FFG  performing  ASW  and  the  CG  will  remain  with  the  CV  unless 
required  by  the  DDG  to  meet  a  specific  threat.  In  absence  of  such  a  specific  threat,  CV  is  considered  a 
more  likely  target  for  the  enemy. 

J.  (FOUO)  CV  has  priority  against  land  based  Silkworm  sites  and  helicopters. 

K.  (FOUO)  The  fighters  will  man  at  least  2  CAP  stations. 

L.    (FOUO)  DDG's  will  be  in  position  to  provide  NSFS  support  against  artillery 
strong-points,  and  will  man  fire  support  stations  (FSS)  about  4  miles  directly  east  of  the  port. 


GENTEXT/ ADMIN  AND  LOG/ 

9.  (FOUO)  Per  CINCMED  OPLAN  1234,  as  amended  herein.// 
GENTEXT/COMMAND  AND  SIGNAL/ 

10.  (FOUO)  USCINCMED  is  supported  CINC. 

1 1 .  (FOUO)  CJTF  4  is  on-the-scene  Commander  and  will  exercise  OPCON  of  advance  forces  until  HQ 
USCINCMED  FWD  is  activated. 

12.  (FOUO)  Command  relationships  as  outlined  in  Annex  J,  CINCMED  OPLAN  1234. 
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13.  (FOUO)  Communications  guidance  as  outlines  in  Annex  K,  CINCMED  OPLAN  1234  as  amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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IMMEDIATE 


NTA 


FROM:  USCINCMED  NAPLES  IT 

CJTF  FOUR 

TO:  CJCS  WASHINGTON  DC 

USCINCCENT  MACDILL  AFB  FL 
USCINCLANT  NORFOLK  VA 
USCINCEUR  VAIHINGEN  GE 
CINCFOR  FT  MCPHERSON  GA 
USCINCPAC  HONOLULU  HI 
USCINCTRANS  SCOTT  AFB  IL 
USCINCSTRAT  OFFUTT  AFB  NE 
COMMARFORPAC  HONOLULU  HI 
CINCPACFLT  HONOLULU  HI 
JTF  FOUR 

INFO:  WHITEHOUSE  SITUATION  ROOM  WASHINGTON  DC 

SECSTATE  WASHINGTON  DC 
SECDEF  WASHINGTON  DC 
CSA  WASHINGTON  DC 
CMC  WASHINGTON  DC 
CNO  WASHINGTON  DC 


DISTR: 


CINC/DCINC/CCJ1/CCJ2/CCJ3/CCJ4/CCJ5/CCJ6 


FOR  OFFICIAL  USE  ONLY 

OPER/THUNDER  SPEAR// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPECIAL  HANDLING  INSTRUCTIONS 

REF/A/ORDER/CJCS/01 1742Z  NOV  96// 

REF/B/ORDER/CJCS/041 142Z  NOV  96// 

NARR/JT  STRAT  CAP  PLN  (FY  96),  CJCS  ALERT  ORDER// 

ORDTYP/OPORD/USCINCCENT  11-96// 

MAP/1015/TUNSIA// 

MAP/1020/YANG// 

NARR/SCALE  1:100,000// 

TIMEZONE/Z// 

HEADING/TASK  ORGANIZATION// 
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UNITS 


/UNITDES 


AJNTTLOC 


/CMNTS 


/USCINCLANT 

/USCINCEUR 

/CINCFOR 

/USCINCPAC 

/USCINCTRANS 

AJSCINCSTRAT 

/COMMARFORPAC 

/CINCPACFLT 

/HQ  USMEDCOM  FWD 

/HQ  USMEDAF  (MINUS) 

/HQ  USNAVMED  (MINUS) 

/SUPPORTING  FORCES 

/COMSUPNAVFOR 

/MPS// 


/NORFOLK  VA 

/VAMINGEN  GE 
/FT  MCPHERSON  GA 

/HONOLULU  HI 
/SCOTT  AFB  IL 

/OFFUTTAFBNE 

/HONOLULU  HI 
/HONOLULU  HI 


12  TAC  ARLFT  SQ 
/6  KC-10 
12  RC-135 

/1MEB 

/(JTF  4) 


GENTEXT/SITUATION 

1 .  (FOUO)  Yang  has  attacked  the  friendly  nation  of  Ying.  Attacking  forces  have  succeeded  in 
seizing  Yingian  port  of  Plethora.  Yingian  government  has  requested  U.S.  assistance  in  taking  back 
port  of  Plethora  and  driving  Yangian  forces  from  Ying. 

A.  (FOUO)  ENEMY  FORCES 

6.   (FOUO)  See  current  SITREP  and  DIN.  Port  of  Plethora  protected  by 

obstructions,  mines,  obstacles,  and  the  presence  of  hidden  enemy  among  the  port  facility  buildings. 
Two  beaches  approx.  5  miles  south  of  the  port  may  be  suitable  for  amphibious  assault.  Northernmost 
beach  (designated  "Red  Beach")  has  road  leading  to  the  port.  Southernmost  beach  (designated  "Blue 
Beach")  has  a  road  leading  to  the  airfield.  Waterborne  approaches  to  the  beaches  are  possibly  mined. 
Commanding  terrain  to  north  of  Red  Beach  believed  occupied  by  enemy  Heavy  Mortar  Platoon  with 
a  platoon  of  Infantry  for  security.  This  terrain  dominates  both  Red  Beach  and  the  port.  Seizure  and 
retention  of  this  dominant  terrain  should  be  considered  essential  for  successful  attack  on  Red  Beach 
and  port. 
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(2)  (FOUO)  Believed  to  be  at  port,  but  hidden  from  view,  is  company-sized  armored 
counterattack  force  that  could  move  toward  Red  Beach  in  response  to  any  amphibious  assault. 
Similar  counterattack  force  may  exist  at  airfield,  which  is  located  about  5  miles  inland  from  the  Blue 
Beach.  These  counterattack  forces  could  inflict  serious  damage  if  not  interdicted  before  they  reach 
either  beach.  Off-road  terrain  between  beach,  port,  airfield,  and  commanding  terrain  is  swampy  and 
treacherous;  and  is  unsuitable  for  travel.  Thus,  all  travel  must  be  on  the  two  roads.  It  is  believed  that 
one  or  both  of  the  roads  will  be  mined.  Locations  of  any  minefields  are  currently  unknown.  Port, 
airfield,  both  roads,  both  beaches,  and  commanding  terrain  are  located  within  range  of  artillery 
strong-points.  Northernmost  strong-point  can  range  Red  Beach  and  port.  Southernmost  strong-point 
can  range  both  Blue  Beach  and  airfield.  Artillery  pieces  are  housed  in  reinforced  concrete  bunkers, 
with  ammunition  stored  in  deep  underground  bunkers.  It  is  unlikely  that  even  concentrated  air 
attacks  will  completely  disable  the  artillery  strong-points.  Enemy  can  be  expected  to  wheel  out 
artillery  pieces  (from  8  to  24  at  a  time),  set  up,  sight  in,  and  fire  within  5  minutes.  If  friendly  forces 
can  get  effective  NSFS  on  target  in  less  than  5  minutes,  the  enemy  will  most  probably  wheel  their 
artillery  pieces  back  into  bunkers  and  wait  until  another  time. 

(3)  (FOUO)  Enemy  also  has  several  Frog  Missile  Launchers  known  to  be  capable  of  carrying 
chemical  munitions.  Frogs  believed  to  be  hidden  in  the  vicinity  of  both  artillery  strong-points.  They 
can  emerge  from  covered  positions,  prepare  warheads,  and  fire  missiles  within  10  minutes.  Past 
experience  has  shown  that  Frog  crews  are  more  stalwart  than  artillery  crews.  They  will  continue  to 
prepare  and  launch  their  missiles  even  if  they  are  being  suppressed  by  NSFS  or  artillery. 

(4)  (FOUO)  Submarine  threat  is  considerable.  Enemy  has  at  least  one  Alfa-Class  submarine 
known  to  be  in  the  area,  and  possibly  more. 

(5)  (FOUO)  Enemy  possess  HIND  Helicopters,  which  have  demonstrated  the  capability  to 
launch  anti-ship  missiles.  The  DDG,  CG  and  CV  possess  capabilities  to  counter  these  helicopters. 

7.   (FOUO)  The  enemy  has  significant  air  strike  capability,  and  can  launch 
anti-ship  missiles  from  most  of  its  strike  aircraft. 

(7)  (FOUO)  The  enemy's  Special  Forces  also  possess  numerous  fast  patrol  boats,  that  can  either 
fire  very  potent  Russian  torpedoes  or  be  loaded  with  explosives  for  suicide  missions. 

(8)  (FOUO)  There  are  Silkworm  threats  throughout  the  area.  The  Silkworm  missiles  are  placed 
in  residential  neighborhoods  because  they  know  U.S.  will  be  reluctant  to  target  residential  areas. 
Accordingly,  if  U.S.  warships  want  to  target  a  Silkworm  launcher,  they  must  first  get  visual 
confirmation  of  its  presence,  using  theater  RECON  (TARPS)  assets,  and  any  strike  must  use 
precision  guided  munitions. 
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B.  (FOUO)  FRIENDLY  FORCES.    JTF  4  will  be  comprised  primarily  of  assets  organic  to 
Mediterranean  Command  (MEDCOM).  A  theater-level  JFACC  and  other  friendly  forces  are 
operating  against  the  enemy  in  Ying,  but  not  in  concert  with  the  JTF. 

(1)  (FOUO)  JTF  4  will  consist  of  one  CV,  one  RECON  (TARPS),  eight  CAS 
Sections  and  subordinate  units  (4.1,  4.2,  4.3,  4.2.1,  4.2.2). 

8.  (FOUO)  JTU  4.1  will  consist  of  three  Rifle  Companies,  one  LHA,  one 
AAAV  Platoon,  two  MV22s,  and  one  Stinger  Detachment. 

(3)  (FOUO)  JTU  4.2  will  consist  of  two  Cobra  Sections. 

9.  (FOUO)  JTU  4.3  will  consist  of  three  Rifle  Companies,  one  LPD,  two 
AAAV  Platoons,  one  MV22,  one  Stinger  Detachment,  and  two  Cobra  Sections. 

(5)  (FOUO)  JTG  4.2.1  will  consist  of  two  DDGs,  one  CG,  one  Engineer  Platoon,  one  Huey 
MEDEVAC,  and  one  MH-53  MCM. 

(6)  (FOUO)  JTG  4.2.2  will  consist  of  two  FFGs,  one  Engineer  Platoon,  one  Huey  MEDEVAC, 
one  MH-53  MCM,  and  eight  Fighter  Sections. 

(7)  (FOUO)  Continuous  coverage  by  RECON  (TARPS)  will  be  maintained  in  general  support 
of  theater  CINC.  May  be  tasked  with  any  immediate  imagery  requirements.// 

GENTEXT/MISSION/ 

2.  (FOUO)  On  order,  JTF  4  ground  forces  will  seize  and  defend  Yingian  Port  of  Plethora,  to  allow 
introduction  of  follow  on  forces  in  support  of  Yingian  government  troops.  Sea-based  forces  will 
support  amphibious  assault  with  CAS,  naval  gunfire,  and  air  defense  assets.// 

GENTEXT/EXECUTION/ 

10.        (FOUO)  CONCEPT  OF  OPERATIONS 

A.  GROUND.  Each  GCE  will  simultaneously  land  one  AAAV-Mounted  Platoon  on  respective 
beach.  JTU  4.1  will  simultaneously  take  commanding  terrain  with  one  MV22.  Once  BOTH  beaches 
and  commanding  terrain  are  secure,  the  two  AAAV-Mounted  Platoons  will  proceed  down  the  roads 
from  their  respective  beaches,  clearing  minefields  with  Engineer  Platoons,  killing  counterattack 
forces  with  Cobra  Sections,  and  conducting  MEDEVACS  as  necessary.    Once  the  roads  have  been 
cleared,  the  AAAV-Mounted  Platoons  will  take  the  port  and  airfield.  It  is  important  that  once  the 
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AAAV-Mounted  Platoons  land  on  the  beach,  the  airfield  and  port  be  taken  as  quickly  as  possible, 
before  the  enemy  has  a  chance  to  organize  his  defense  and  send  reinforcements.  We  would  like  to 
conduct  the  final  assaults  on  the  airfield  and  port  simultaneously,  in  order  to  present  the  enemy 
commander  with  the  most  confusing,  dilemma-filled  environment  possible.  However,  if  one  attack 
must  occur  before  the  other,  the  airfield  has  the  priority. 

B.  MARITIME.  Due  to  hydrographic  limitations,  the  DDG  and  the  CV  will  have  to  be  significantly 
separated  during  the  operation,  enough  to  preclude  them  from  being  under  a  Joint  Air  Defense 
umbrella  provided  by  the  CG.  Thus,  the  CG  will  remain  with  the  CV,  but  will  position  itself  so  that 
it  can  rapidly  move  from  the  CV  to  the  DDG  if  that  becomes  necessary.  Additionally,  the  two 
DDG's  are  inshore,  providing  NSFS  support,  while  the  FFG  is  the  primary  ASW  platform  for  the 
CV.  The  FFG  performing  ASW  will,  like  the  CG,  position  itself  so  that  it  can  quickly  move  to 
support  the  DDG  if  that  is  necessary. 

4.  (FOUO)  TASK  ASSIGNMENT  JTU  4.1.  On  order  from  JTF  4,  land  one  AAAV-Mounted  Platoon 

on  Red  Beach.  Simultaneously  seize  commanding  terrain  to  the  north  of  Red  Beach  with  one  MV22. 
Once  the  beach  and  commanding  terrain  are  secure,  attack  along  the  road  from  the  beach  to  the  port, 
clearing  minefields  with  Engineer  Platoon,  killing  counterattack  forces  with  Cobras  and  conducting 
MEDEVACS  as  necessary.  Once  the  roads  have  been  cleared,  attack  the  port  with  the  AAAV- 
Mounted  Platoon. 

5.  (FOUO)  TASK  ASSIGNMENT  JTU  4.3.  On  order  from  JTF  4,  land  one  AAAV-Mounted  Platoon  on 

Blue  Beach.  Once  the  beach  is  secure,  attack  along  the  road  from  beach  to  airfield  with  AAAV- 
Mounted  Platoon,  clearing  minefields  with  Engineer  Platoon,  killing  counterattack  forces  with 
Cobras,  and  conducting  MEDEVACS  as  necessary.  Once  the  roads  have  been  cleared,  conduct  a 
coordinated  attack  on  the  airfield  with  MV22. 

6.  (FOUO)  TASK  ASSIGNMENT  JTU  4.  Keep  two  elements  of  CAS  on  standby  at  all  times:  one  to  be 

used  against  Frog  or  Scuds,  and  the  other  to  be  used  against  Silkworms.  CV  will  provide  3  sections 
of  air  defense  aircraft,  with  one  CAP  station  over  the  CV  and  the  others  over  the  DDGs. 

7.  (FOUO)  TASK  ASSIGNMENT  JTG  4.2,  JTG  4.2. 1  and  JTG  4.2.2.  On  order  from  JTF  4,  JTG  4.2 

will  coordinate  JTG  4.2.1  and  JTG  4.2.2  to  clear  mines  from  Red  and  Blue  Beaches,  and  launch 
Marines  for  assault  on  Red  and  Blue  Beaches.  Additionally,  JTG  4.2  will  coordinate  JTG  4.2. 1  and 
JTG  4.2.2  to  defend  northern  and  southern  sectors,  provide  NSFS  for  artillery  strong-points,  provide 
MEDEVAC  support,  provide  Engineer  support,  provide  ASW  with  the  FFGs  and  provide  fighter 
support.  JTG  4.2  will  provide  Cobra  support. 

8.  (FOUO)  COORDINATING  INSTRUCTIONS. 
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A.  (FOUO)  This  order  effective  for  planning  upon  receipt  and  execution  on  order. 

B.  (FOUO)  Dirlauth  for  planning  and  operations  with  Info  CJCS  and  CINCMED. 

C.  (FOUO)  ROE  will  be  per  CINCMED  OPLAN  1234. 

D.  (FOUO)    If  the  airfield  attack  is  held  up  for  any  reason,  the  port  attack  will  be 

delayed  to  retain  the  synergism  of  concurrent  attacks.  If  the  port  attack  is  held  up,  the  airfield  attack  will 
go  forward. 

E..  (FOUO)  Unit  4.3's  attack  on  the  airfield  has  priority,  because  buildup  of  forces 
can  be  most  quickly  and  effectively  achieved  through  air  transport. 

F.  (FOUO)  Enemy  patrol  boats  or  other  surface  craft  will  be  engaged  by  the  DDGs. 

G.  (FOUO)    If  both  the  DDG  and  the  CV  are  threatened  by  the  enemy,  the  DDG  has 
priority  of  support  against  submarine  threats,  fixed-wing  air  threats,  and  patrol  boats. 

H.  (FOUO)  If  there  is  a  threat  of  an  air  attack  against  the  DDG,  the  DDG  will  be  protected  by  the 
CG  or  a  CAP. 

I.  (FOUO)  The  FFG  performing  ASW  and  the  CG  will  remain  with  the  CV  unless 
required  by  the  DDG  to  meet  a  specific  threat.  In  absence  of  such  a  specific  threat,  CV  is  considered  a 
more  likely  target  for  the  enemy. 

J.  (FOUO)  CV  has  priority  against  land  based  Silkworm  sites  and  helicopters. 

K.  (FOUO)  The  fighters  will  man  at  least  2  CAP  stations. 

L.  (FOUO)  DDG's  will  be  in  position  to  provide  NSFS  support  against  artillery  strong-points,  and 
will  man  fire  support  stations  (FSS)  about  4  miles  directly  east  of  the  port.  // 

M.  (FOUO)  Stringers  are  the  only  Close  Air  Support  weapon  available  to  JTF  4.1.1  and 
JTF  4.3.1.// 

GENTEXT/ADMIN  AND  LOG/ 

9.  (FOUO)  Per  CINCMED  OPLAN  1234,  as  amended  herein.// 

GENTEXT/COMMAND  AND  SIGNAL/ 
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10.  (FOUO)  USCINCMED  is  supported  CINC. 

1 1 .  (FOUO)  CJTF  4  is  on-the-scene  Commander  and  will  exercise  OPCON  of  advance  forces  until  HQ 
USCINCMED  FWD  is  activated. 

12.  (FOUO)  Command  relationships  as  outlined  in  Annex  J,  CINCMED  OPLAN  1234. 

13.  (FOUO)  Communications  guidance  as  outlines  in  Annex  K,  CINCMED  OPLAN  1234  as  amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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IMMEDIATE 


F2 


FROM:  USCINCMED  NAPLES  IT 

CJTF  FOUR 


TO: 


CJCS  WASHINGTON  DC 
USCINCCENT  MACDILL  AFB  FL 
USCINCLANT  NORFOLK  VA 
USCINCEUR  VAIHINGEN  GE 
CINCFOR  FT  MCPHERSON  GA 
USCINCPAC  HONOLULU  HI 
USCESfCTRANS  SCOTT  AFB  IL 
USCINCSTRAT  OFFUTT  AFB  NE 
COMMARFORPAC  HONOLULU  HI 
CINCPACFLT  HONOLULU  HI 
JTFFOUR 


INFO: 


WHITEHOUSE  SITUATION  ROOM  WASHINGTON  DC 

SECSTATE  WASHINGTON  DC 

SECDEF  WASHINGTON  DC 

CSA  WASHINGTON  DC 

CMC  WASHINGTON  DC 

CNO  WASHINGTON  DC 


DISTR: 


CINC/DCINC/CCJ1/CCJ2/CCJ3/CCJ4/CCJ5/CCJ6 


FOR  OFFICIAL  USE  ONLY 

OPER/THUNDER  SPEAR// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPECIAL  HANDLING  INSTRUCTIONS 

REF/A/ORDER/CJCS/01 1742Z  NOV  96// 

REF/B/ORDER/CJCS/041 142Z  NOV  96// 

NARR/JT  STRAT  CAP  PLN  (FY  96),  CJCS  ALERT  ORDER// 

ORDTYP/OPORD/USCINCCENT  11-96// 

MAP/1015/TUNSIA// 

MAP/1020/YANG// 

NARR/SCALE  1:100,000// 

TIMEZONE/Z// 

/ARG  55.2 

/  1  MEB 
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/MPS// 
GENTEXT/SITUATION 

1 .  (FOUO)  Yang  has  attacked  the  friendly  nation  of  Ying.  Attacking  forces  have  succeeded  in  seizing 
Yingian  port  of  Plethora.  Yingian  government  has  requested  U.S.  assistance  in  taking  back  port  of 
Plethora  and  driving  Yangian  forces  from  Ying. 

A.  (FOUO)  ENEMY  FORCES  See  OPORDER  Thunder  Spear. 

B.  (FOUO)  FRIENDLY  FORCES.  See  OPORDER  Thunder  Spear. 
GENTEXT/MISSION/ 

2.  (FOUO)  On  order,  JTF  4  will  conduct  a  NEO  at  Plethora.// 
GENTEXT/EXECUTION/ 

3.  (FOUO)  CONCEPT  OF  OPERATIONS. 

A.  (FOUO)  Conduct  Noncombatant  Evacuation  Order  to  remove  United  States  citizens  located  in 
and  around  the  port  of  Plethora.  IAW  Operation  Thunder  Spear.  Special  Forces  personnel  will  be 
provided  for  the  execution  of  the  NEO  Operation.  Current  chain  of  command  may  be  altered  to  carry 
out  this  mission.// 

4.  (FOUO)  COORDINATING  INSTRUCTIONS. 

A.  (FOUO)  This  order  effective  for  planning  upon  receipt  and  execution  on  order. 
GENTEXT/ ADMIN  AND  LOG/ 

5.  (FOUO)  Per  OPORDER  Thunder  Spear.// 
GENTEXT/COMMAND  AND  SIGNAL/ 

6.  (FOUO)  USCINCMED  is  supported  CINC.// 

7.  (FOUO)  CJTF  4  is  on-the-scene  Commander  and  will  exercise  OPCON  of  advance  forces  until  HQ 

USCINCMED  FWD  is  activated. 

8.  (FOUO)  Command  relationships  as  outlined  in  Annex  J,  CINCMED  OPLAN  1234. 
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9.  (FOUO)  Communications  guidance  as  outlines  in  Annex  K,  CINCMED  OPLAN  1234  as  amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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IMMEDIATE 


F3 


FROM: 


USCINCMED  NAPLES  IT 
CJTF  FOUR 


TO: 


CJCS  WASHINGTON  DC 
USCINCCENT  MACDILL  AFB  FL 
USCINCLANT  NORFOLK  VA 
USCINCEUR  VAIHINGEN  GE 
CINCFOR  FT  MCPHERSON  GA 
USCINCPAC  HONOLULU  HI 
USCESfCTRANS  SCOTT  AFB  IL 
USCINCSTRAT  OFFUTT  AFB  NE 
COMMARFORPAC  HONOLULU  HI 
CINCPACFLT  HONOLULU  HI 
JTFFOUR 


INFO: 


WHrrEHOUSE  SITUATION  ROOM  WASHINGTON  DC 

SECSTATE  WASHINGTON  DC 

SECDEF  WASHINGTON  DC 

CSA  WASHINGTON  DC 

CMC  WASHINGTON  DC 

CNO  WASHINGTON  DC 


DISTR: 


CINC/DCINC/CCJ 1 /CC  J2/CCJ3/CC  J4/CCJ5/CCJ6 


FOR  OFFICIAL  USE  ONLY 

OPER/THUNDER  SPEAR// 

MSGED/ORDER/USCINCCENT// 

AMPN/SPECIAL  HANDLING  INSTRUCTIONS 

REF/A/ORDER/CJCS/01 1742Z  NOV  96// 

REF/B/ORDER/CJCS/041 142Z  NOV  96// 

NARR/JT  STRAT  CAP  PLN  (FY  96),  CJCS  ALERT  ORDER// 

ORDTYP/OPORD/USCINCCENT  11-96// 

MAP/10 15/TUNSIA// 

MAP/1020/YANG// 

NARR/SCALE  1:100,000// 

TTMEZONE/Z// 

/1MEB 

/MPS// 
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GENTEXT/SITUATION 

1 .  (FOUO)  Yang  has  attacked  the  friendly  nation  of  Ying.  Attacking  forces  have  succeeded  in  seizing 
Yingian  port  of  Plethora.  Yingian  government  has  requested  U.S.  assistance  in  taking  back  port  of 
Plethora  and  driving  Yangian  forces  from  Ying. 

A.  (FOUO)  ENEMY  FORCES  See  OPORDER  Thunder  Spear. 

B.  (FOUO)  FRIENDLY  FORCES.  See  OPORDER  Thunder  Spear. 

GENTEXT/MISSION/ 

2.  (FOUO)  JTF  4  can  reorganize  the  current  chain  of  command  and  unit  assets  prior  to  execution  of 

Operation  Thunder  Spear.// 

GENTEXT/EXECUTION/ 

3.  (FOUO)  CONCEPT  OF  OPERATIONS. 

A.  (FOUO)  JTF  personnel  will  evaluate  current  command  structure  and  unit  assets. 
Changes  can  be  made  to  the  chain  of  command  and/or  the  unit  assets  to  create  a  "better"  structure  for  the 

execution  of  Operation  Thunder  Spear.// 

1.   (FOUO)  TASK  ASSIGNMENT  JTF  4.  JTF  4  will  provide  the  following  assets  to  JTF  195 

1  LPD  1  LHA  2  Rifle  Co  2  Cobra  Sections 

1  Eng.  Pit  1  MEDEVAC    1  MCM  1  Stinger  Detachment 

2  CAS  2  Fighters  1  DDG  1  FFG 
1  AAAV  1  MV22 

5.  (FOUO)  COORDINATING  INSTRUCTIONS. 

A.  (FOUO)  This  order  effective  for  planning  upon  receipt  and  execution  on  order. 

B.  (FOUO)  There  are  NO  restrictions  on  how  the  units  can  be  reconstructed. 
GENTEXT/ ADMIN  AND  LOG/ 

6.  (FOUO)  Per  OPORDER  Thunder  Spear.// 
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GENTEXT/COMMAND  AND  SIGNAL/ 

7.  (FOUO)  USCINCMED  is  supported  CINC.// 

8.  (FOUO)  CJTF  4  is  on-the-scene  Commander  and  will  exercise  OPCON  of  advance  forces  until  HQ 

USCINCMED  FWD  is  activated. 

9.  (FOUO)  Command  relationships  as  outlined  in  Annex  J,  CINCMED  OPLAN  1234. 

10.  (FOUO)  Communications  guidance  as  outlines  in  Annex  K,  CINCMED  OPLAN  1234  as  amended 
herein.// 

AKNLDG/Y// 

DECL/OADR// 
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TASK 

NAME 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

HILL 

1  RIFLE  CO 
1  CAS 

1  RIFLE  CO 
2DDG 

1  RIFLE  CO 

IDDG 

1FFG 

1  RIFLE  CO 
ICG 

1FFG 

RED  BEACH 

1  CAS 

2DDG 

IDDG 
1FFG 

1  COBRA  SEC 

BLUE 
BEACH 

1  RIFLE  CO 
ICAS 

1  RIFLE  CO 
2DDG 

1  RIFLE  CO 

IDDG 

1FFG 

1  RIFLE  CO 
1  COBRA  SEC 

ARTILLERY 

IDDG 

ICAS 

2  FFG 

FROG 
LAUNCH 

IDDG 

ICAS 

2  FFG 

SILKWORM 

ICAS 

MINE  LAND 

1  ENG  PLT 

MINE  SEA 

1MCM 
HELO 

STRIKE  AIR 

1  FIGHTER 
SEC 

1STNGR 
DETCH 

IDDG 

ICG 

TACAIR 

IDDG 

ICG 

HELO 

1  FIGHTER 
SEC 

1STNGR 
DETCH 

IDDG 

ICG 

TANKS 

1  COBRA 
SEC 

2DDG 

IDDG 
ICAS 

1  CAS 

1  RIFLE  CO 

PATROL 
BOAT 

1  FFG 

1  COBRA 
SEC 

IDDG 

ICG 

PATROL 
BOAT 

1  CAS 

SUB 

1FFG 

ASCM 

1  FIGHTER 
|  SEC 

IDDG 

ICG 
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TASK 

NAME 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

POSSIBLE 
RESOURCE 
COMBO 

MEDIVAC 

1MED  HELO 

HOLD 

1  RIFLE  CO 

SILKWORM 
AIR 

1  FIGHTER 
SEC 

1DDG 

ICG 

SEAPORT 

2  RIFLE  CO 
2  RIFLE  CO 

2  RIFLE  CO 
ICG 

2  RIFLE  CO 
1  COBRA  SEC 

2  RIFLE  CO 
1  CAS 

AIRPORT 

2  RIFLE  CO 
2  RIFLE  CO 

2  RIFLE  CO 
ICG 

2  RIFLE  CO 
1  COBRA  SEC 

2  RIFLE  CO 
1  CAS 
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The  DDD  Graphical  User  interface 

The  DDD  graphical  user  interface  displays  a  map  on  the  left  side  of 
the  screen  which  is  a  graphical  representation  of  friendly  and  enemy 
platforms.  Within  the  map,  land  is  represented  by  squares  which  have  a 
brown  tint,  and  sea  by  squares  which  are  white.  The  mouse  commands 
listed  in  the  next  section  will  describe  how  friendly  platforms  on  the  map 
may  be  manipulated  and  how  information  on  enemy  platforms  is  obtained. 
The  right  half  of  the  screen  contains  four  buttons: 

Start/Refresh:  The  Start  button  is  used  only  at  the  beginning  of  a  scenario  to 

start  all  of  the  stations  playing.  Once  the  scenario  has  begun,  the  button 

changes  to  Refresh.  Left  clicking  on  the  Refresh  button  redraws  the  map 

eliminating  any  undesired  traces  which  may  appear. 

Zoom  In:  Allows  the  user  to  zoom  in  for  a  more  detailed  look  at  a  particular 

section  of  the  map.  To  zoom  in,  left  click  on  the  "Zoom  In"  button.  Move  the 

cursor  over  to  map  and  left  click  at  a  point  to  the  left  or  right  of  where  the 

area  of  interest  lies.  While  continuing  to  hold  the  left  mouse  button 

depressed,  drag  the  cursor  and  a  box  will  begin  to  appear  showing  the  area 

which  will  be  zoomed  in  on. 

Zoom  Out:  Left  clicking  on  this  button  returns  the  map  to  the  previous  map 

size. 

Cancel:  Left  Clicking  on  the  Cancel  button  allows  the  user  to  suspend  an 

operation  on  an  asset  such  as  a  move  or  an  attack  prior  to  completing  the 

mission. 

The  right  half  of  the  screen  also  contains  a  time  bar.  When  a 
friendly  platform  or  sub-platform  is  selected  to  perform  an  action  (i.e. 
launch  aircraft,  attack),  a  white  arrow  will  appear  next  to  this  bar  showing 
the  amount  of  time  to  complete  this  mission.  The  platform  cannot  perform 
any  other  action  until  this  action  is  completed.  In  addition,  above  the  time 
bar  are  several  other  pieces  of  information.  The  color  of  the  stick  man 
figure  in  a  box  shows  the  color  of  the  platforms  on  the  map  which  your 
station  controls.  Next  to  this  box  is  the  name  of  the  station  you  are  playing 
(i.e.  CJTF  4,  CJTG  4.1 ,  etc.)  Below  the  box  are  two  counters  which 
display  feedback  on  how  well  the  entire  team  is  doing  on  the  scenario. 
The  counter  labeled  mission  starts  at  zero  and  increments  as  missions 
are  accomplished.  The  counter  labeled  strength  starts  at  1 00  and 
decrements  as  your  force  strength  is  decreased. 

The  lower  portion  of  the  screen  contains  two  window  dialog  boxes. 
Close  attention  must  be  given  to  the  window  on  the  left  as  this  box 
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displays  messages  between  the  various  players  which  may  require  some 
action  to  be  taken  by  your  station.  The  right  window  can  best  be  described 
as  a  confirmation  window.  Summaries  of  messages  or  actions  performed 
by  your  station  will  appear  in  this  window  along  with  some  messages 
about  the  status  of  other  friendly  platforms.  Also,  the  very  bottom  of  the 
screen  below  these  two  windows  displays  warning  and  error  prompts.  A 
beep  will  occur  along  with  a  warning  or  error  message  following  any  action 
performed  by  your  station  which  is  not  allowed  (i.e.  Attempting  to  attack 
the  enemy  when  your  unit  is  out  of  range). 


Using  the  Mouse  in  DDD 

A  standard  three  button  mouse  is  used  when  running  a  scenario  at 
each  workstation.  When  clicking  on  an  platform  in  DDD  each  mouse 
button  serves  a  different  function  depending  on  whether  the  platform  is 
friend  or  foe,  and  if  friend  whether  or  not  the  platform  is  owned  or  not 
owned  by  you. 

Left  Mouse  Button 

The  left  mouse  button  clicked  on  an  platform  will  just  select  it.  The 
left  mouse  button  is  also  used  to  carry  out  options  from  a  Right  Mouse 
Menu  covered  on  the  next  page. 

Middle  Mouse  Button 

When  the  middle  button  is  clicked  on  an  platform,  the  window 
presented  depends  on  whether  the  platform  is  a  (1)  friendly  platform  or 
sub-platform  or  (2)  enemy  platform.  If  the  platform  is  an  enemy  platform  , 
a  window  appears  which  provides  known  information  about  the  attributes 
of  the  platform.  If  a  friendly  platform  is  selected,  a  screen  appears  which 
displays  the  attributes  of  that  platform  or  sub-platform.  A  friendly  platform 
will  show  the  attributes,  ownership,  and  the  number  of  all  sub-platforms 
located  on  the  platform  is  also  shown.  (Platforms  are  the  major  friendly 
platforms  in  the  scenarios.  Sub-platforms  are  platforms  such  as  aircraft, 
Stinger  detachments,  engineering  platoons,  helicopters,  etc.  which  are 
carried  by  a  platform.  The  ownership  of  any  sub-platform  may  or  may  not 
be  the  same  as  the  owner  of  the  platform  it  is  being  carried  on). 

When  a  friendly  platform  is  selected  with  the  middle  mouse  button, 
the  portion  of  the  window  where  the  sub-platforms  are  listed  is  used  to 
launch  or  request  launch  of  a  sub-platform  depending  on  where  the  sub- 
platform  is  located.  There  are  three  possible  situations  which  can  occur 
here: 
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1.  Sub-platform  needed  to  be  launched  is  on  a  platform  owned  by  you:  In  this 
case  you  can  launch  any  sub-platform  on  your  platform  whether  you  own  it  or 
not.  This  is  done  by  left  clicking  on  the  right  arrow  key  in  the  line  for  the 
number  of  sub-platform(s)  needed  and  then  clicking  OK. 

2.  Sub-platform  needed  to  be  launched  is  owned  by  vou.  but  is  located  on  a 
platform  which  you  do  not  own: 

a)  In  this  case  middle  click  on  the  platform  where  your  sub-platform  is 
located. 

b)  Left  click  on  the  arrow  located  in  the  line  of  the  sub-platform 
needed  until  the  desired  number  of  sub-platforms  to  be  launched  is 
set 

c)  Left  click  on  OK.  A  message  will  then  be  sent  to  the  owner  of  the 
platform  where  your  sub-platform  is  located  requesting  that  it  be 
launched.  It  is  the  responsibility  of  the  person  where  your  sub- 
platform  resides  to  launch  it. 

1.   Sub-platform  needed  is  not  owned  by  vou  and  is  located  on  a  platform  not 
owned  by  vou:  In  this  case  middle  click  on  the  platform  where  the  sub- 
platform  needed  resides.  Left  click  on  the  arrow  on  the  line  containing  the 
sub-platform  desired  until  the  required  number  is  set,  and  then  left  click  on 
OK.  A  message  will  then  be  forwarded  up  your  chain  of  command  which  must 
be  acted  upon  by  your  immediate  superior  to  obtain  this  sub-platform. 

The  lower  portion  of  this  screen  also  offers  options  for  displaying 
information  on  range  for  both  sensors  and  weapons  of  a  friendly  platform 
against  enemy  ground,  air,  or  sea  assets.  The  sensor  option  will  display 
four  range  rings  around  the  platform: 

1 )  The  outermost  black  ring  represents  the  detection  range. 

2)  The  next  inner  black  ring  represents  the  range  at  which  measurements 
on  the  enemy  can  be  made. 

3)  The  furthest  inner  black  ring  represents  the  visual  detection  range. 

4)  The  inner  yellow  ring  represents  the  range  at  which  the  platform  is 
vulnerable. 


The  weapons  option  displays  a  single  red  ring  around  the  platform 
which  shows  the  effective  range  of  its  weapon.  To  display  these  range 
rings  left  click  on  either  sensors,  weapon,  or  both,  and  then  left  click  what 
type  of  medium  to  display  these  for  (air,  ground,  or  sea).  To  turn  the  range 
rings  off,  middle  click  on  the  platform  and  left  click  on  none. 

Right  Mouse  Button 
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The  right  mouse  button  will  cause  a  menu  to  pop  up.  The  following 
sections  describe  the  options  presented  depending  on  the  platform 
selected  with  the  right  mouse  button. 

Friendly  platform  which  you  do  not  own:  The  menu  that  pops  up  will 
present  the  option  of  requesting  the  asset,  forcing  the  transfer  of  the 
asset,  or  information  on  the  asset.  Explanations  of  these  options  follow: 

Request  (REQ):  The  menu  requires  input  for  who  the  request  is  to,  and  the 
urgency  of  the  request.  All  items  must  be  selected.  When  the  choices  are 
completed,  a  message  is  sent  to  the  person  selected  if  they  are  directly  in 
your  chain  of  command  or  up  your  chain  of  command  where  your  superior 
must  take  action  on  the  request. 

Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

Friendly  platform  which  you  own:  This  menu  will  allow  the  choices  of 
Move,  Pursue,  Attack,  Return,  Transfer,  or  Information.  An  explanation  of 
these  options  follow: 

Move:  Selecting  move  will  cause  a  cross-hair  type  symbol  to  appear.  Position 
this  cross  hair  to  the  place  the  platform  is  desired  to  be  moved  and  single 
click  with  the  left  mouse  button.  The  platform  will  then  move  to  this  position. 
When  it  arrives  there,  it  will  stop  until  another  command  to  move  is  given. 

•  Pursue:  Selecting  pursue  will  cause  the  cursor  to  change  to  a  finger.  Place 
the  finger  on  the  enemy  platform  desired  to  be  pursued,  left  click,  and  your 
platform  will  then  move  to  pursue  it. 

•  Attack:  When  this  option  is  selected  a  question  mark  will  appear.  Place  the 
question  mark  on  the  platform.  If  in  range  to  perform  this  action,  a  menu  will 
then  appear  which  shows  the  attributes  of  the  platform  selected  to  perform 
the  attack  and  the  attributes  of  the  platform  that  the  attack  is  to  be  performed 
on.  The  option  is  then  given  to  carry  out  the  mission  or  to  cancel  the 
assignment. 

•  Coordinated  Attack:  If  the  platform  selected  to  attack  the  enemy  does 
not  have  enough  combat  power  to  accomplish  the  mission,  a  coordinated  attack 
may  be  performed.  It  should  be  noted  that  the  following  explanations  of  how  to 
do  a  coordinated  attack  will  work  only  if  all  of  the  platforms  are  within  attack 
range. 

•  Coordinated  Attack  using  Two  Platforms:  A  coordinated  attack  using 
two  platforms  is  accomplished  by  first  selecting  one  of  the  two  platforms  to 
perform  the  coordinated  attack  with  the  left  mouse  button,  and  then  right  clicking 
on  the  second  platform  performing  the  attack.  The  menu  will  then  pop  up  and 
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select  the  attack  option.  The  cursor  will  then  change  to  the  question  mark.  Place 
it  on  the  platform  which  is  to  be  attacked  and  left  click  with  the  mouse. 

•  Coordinated  Attack  using  Three  or  More  Platforms:  To  perform  a 
coordinated  attack  with  three  or  more  platforms,  left  click  on  the  first  platform 
performing  the  attack.  Then,  while  holding  the  shift  key  down  on  the  keyboard, 
left  click  on  all  but  one  of  the  remaining  platforms  performing  the  attack. 
Release  the  shift  key  and  right  click  on  the  final  platform.  The  menu  will  pop  up 
and  select  attack.  The  cursor  will  change  to  a  question  mark.  Place  it  on  the 
platform  to  be  attacked  and  left  click. 

A  simultaneous  attack  by  two  or  more  players  may  be  needed  to  bring 
sufficient  combat  power  to  bear.  These  should  be  coordinated  using  the  voice 
net. 

•  Return:  This  option  may  only  be  used  for  sub-platforms.  Selecting  this  option 
will  cause  the  sub-platform  to  return  to  the  platform  it  originated  from.  The 
sub-platform  will  not  move  towards  its  originating  platform,  but  instead  will 
change  to  a  box  with  a  "x"  in  it  to  simulate  returning  to  its  originating  platform. 
The  return  option  has  been  disabled  on  some  sub-platforms  in  the  scenario. 
If  one  of  these  sub-platforms  is  directed  to  return,  an  error  message  will 
appear. 

•  Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

Enemy  Platforms:  The  menu  presented  in  this  instance  presents  the 
options  of  Identify,  Requesting  Information,  Transferring  Information, 
Coordinating  Action,  Assigning,  and  Information.  Explanations  of  these 
options  follow: 

•  Identify:  This  option  is  normally  used  to  identify  enemy  platforms  or  s  for 
which  the  identity  is  unknown.  This  will  be  readily  apparent  in  a  scenario  as 
the  first  letter  shown  with  the  icon  will  be  followed  by  a  question  mark.  The 
first  letter  designates  which  medium  the  unknown  contact  operates  in.  "A?" 
denotes  an  unknown  air  contact;  "G?"  denotes  an  unknown  ground  contact; 
"S?"  denotes  an  unknown  sea  contact.  Selecting  the  identify  option  will  cause 
a  menu  to  pop  up  which  shows  the  known  attributes  of  the  platform  as  seen 
by  each  player  in  the  scenario.  If  a  friendly  platform  having  sensors  capable 
of  identifying  the  enemy  platform  is  within  sensor  range  the  platform  will  be 
identified  correctly.  If  not,  the  question  mark  will  remain.  This  will  be  apparent 
by  looking  at  the  lower  left  hand  column  where  the  identity  will  be  shaded 
from  a  list  of  possible  identities.  Click  the  fused  button  near  the  top  left  hand 
corner  and  then  OK.  The  identity  of  the  platform  will  then  appear  correctly  on 
the  map  and  its  icon  will  change  to  its  correct  identity. 
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The  following  tables  give  descriptions  of  the  two  letter  symbols  which  will  be 
the  options  shown  when  identifying  an  platform: 


Unknown  Ground 

Description 

t 

Unknown 

HL 

Ground  mission  of  takina  a  hill 

AP 

Airport  around  mission 

SP 

SeaDort  around  mission 

HD 

Holdinq  or  occuovina  around 

TK 

Takinq  a  qround  mission 

AT 

Enemy  artillery 

FG 

Enemy  Froq  launcher 

SWG 

Enemy  Silkworm  missile  launcher 

TN 

Enemy  tanks.  trooDS.  or  vehicles 

NU 

Neutral 

MN 

Land  Mines 

Unknown  Air 

Description 

9 

Unknown 

AS 

Enemv  attack  aaainst  shiDS 

AG 

Enemy  attack  aaainst  around  forces 

HH 

Enemv  helo  attack  aaainst  ships 

NU 

Neutral 

SWA 

Silkworm  missile  in  fliqht 

Unknown  Sea 

Description 

0 

Unkngwn 

MS 

Sea  mines 

PB 

Enemv  Datrol  boats 

SS 

Enemy  submarines 

ML 

Enemv  anti-shiD  cruise  missiles 

NU 

Neutral 

•  Request  Information  (REQ  INFO):  Selecting  this  option  will  cause  a  menu  to 
pop  up  which  allows  you  to  select  an  other  player,  or  all  other  players  from 
whom  you  wish  to  obtain  information  on  the  enemy  platform.  Select  the 
person(s)  and  click  OK.  A  message  will  then  be  sent  to  the  person(s) 
notifying  them  that  this  information  is  requested. 

•  Transfer  Information  (XFR  INFO):  Selecting  this  option  will  cause  a  menu 
to  pop  up  which  allows  you  to  select  a  particular  individual,  or  all  the  players 
you  wish  information  on  the  enemy  platform  to  be  sent  to  .  Select  the 
person(s)  and  click  OK.  A  message  will  then  be  sent  to  the  person(s) 
selected. 

•  Coordinate  Action  (CRD  ACTION):  The  use  of  this  option  allows  messages 
to  be  sent  between  players  concerning  action  requests,  support,  or  intent 
against  an  enemy  platform.  When  selected,  a  menu  pops  up  displaying 
options  for  choosing  who  the  message  is  to  sent  to  and  a  list  of  messages 
which  may  be  sent.  The  following  messages  may  be  sent: 

1.  I  plan  to  handle. 

2.  I  plan  to  support. 

3.  I  cannot  handle. 

4.  I  cannot  support. 

5.  Can  you  handle  ? 

6.  Can  you  support  ? 

Select  the  person  the  message  is  to  be  sent  to,  a  message  is  to  be  sent,  and 
click  OK.  The  message  will  then  be  sent  to  the  person  selected. 

•  Assign:  This  option  may  only  be  used  if  you  are  playing  a  position  where 
you  are  superior  to  someone  in  the  chain  of  command  and  may  only  be 
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directed  at  those  people  who  are  subordinate  to  you.  This  option  will  cause  a 
question  mark  to  appear.  Place  it  on  the  enemy  platform  desired  to  be 
assigned  and  left  click.  A  menu  will  then  appear  which  allows  selecting  whom 
in  the  chain  of  command  it  is  to  be  assigned  to.  Left  click  on  the  person 
desired  to  assign  the  mission  to  and  click  OK.  A  message  will  then  be  sent  to 
that  person  notifying  them  they  are  responsible  for  taking  care  of  the  mission. 

Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

List  of  Platforms  in  the  Scenario 
Terrain  and  task  platforms 

The  following  shows  representations  of  the  icons  which  represents 
terrain  or  task  platforms  in  the  scenarios. 

JkI  Swamp:  The  swamp  icon  indicates  areas  which  mechanized  or 
infantry  units  should  not  traverse.  Friendly  units  will  not  be  destroyed  by 
going  into  these  areas,  but  total  strength  will  be  diminished. 

iHI     Airfield:  The  airfield  icon  is  the  objective  or  mission  to  completed 
by  CJTU  4.1 .1 .  This  airfield  has  attributes  associated  with  it  which  must 
be  compared  to  the  attacking  force  attributes  to  determine  if  the 
necessary  force  is  available. 

Beljcxflt]  Port:  The  port  is  the  objective  or  mission  of  CJTU  4.3.1 .  It, 
like  the  airfields,  also  has  attributes  which  must  first  be  determined  and 
compared  to  attacking  forces  attributes  to  determine  if  enough  combat 
power  can  be  brought  to  bare  to  achieve  this  objective. 


& 


Hill:  The  hill  is  commanding  terrain  between  the  port  and  airfield 
which  must  be  captured  by  CJTU  4.3.1 .  It  is  surrounded  by  swamps  on 
both  sides  which  means  the  only  way  of  accomplishing  this  mission  is  by 
using  AAAV  or  MV-22  sub-platforms. 

■      Task:  The  task  icon  has  attributes  which  must  first  be  identified  and 
then  a  determination  made  as  to  the  best  asset  available  to  complete  this 
task.  Tasks  are  normally  used  to  represent  enemy  ground  forces  in  a 
given  location  which  must  be  eliminated. 

Medivac:  The  medivac  icon  is  a  mission  which  may  appear  after 
friendly  ground  platforms  or  sub-platforms  engage  enemy  platforms  .  The 
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task  has  attributes  which  must  be  determined.  The  mission  is  completed 
by  attacking  it  with  the  medivac  helicopter  (MED  sub-platform). 

*^ 'Hold:  The  hold  icon  may  appear  after  completion  of  a  mission 

(i.e.  attacking  the  hill).  If  this  occurs  the  asset  used  to  perform  the  mission 
must  remain  in  its  current  position  and  may  not  be  used  to  perform  any 
other  mission. 

Enemy  Assets 

The  following  section  shows  the  icons  which  represent  enemy 
forces  that  may  or  may  not  appear  in  a  scenario.  The  text  which  follows 
each  icon  describes  the  enemy  platforms  capabilities  and  the  friendly 
weapon  of  choice  to  use  against  it. 

J^.  Artillery:  Enemy  artillery  pieces  may  pop  up  at  various  times. 
When  they  appear,  they  take  approximately  5  minutes  to  set  up  before 
they  are  able  to  fire.  The  pieces  are  stored  in  reinforced  concrete  bunkers 
with  the  ammunition  stored  in  deep  underground  bunkers.  The  methods 
by  which  enemy  artillery  may  be  suppressed  is  through  the  use  of  Naval 
Surface  Fire  support  (NSFS),  Close  Air  Support  (CAS),  or  Cobra  attack 
helicopter.    NSFS  can  be  accomplished  by  either  the  DDG  or  CG.  Once 
the  artillery  pieces  begin  to  move  toward  you,  which  simulates  firing,  you 
will  be  unable  to  attack  them. 


^ 


Mines:  The  enemy  possesses  the  possibility  of  deploying  both 
land  and  sea  mines.  If  encountered  and  moved  through  by  friendly  forces 
the  total  effectiveness  of  these  forces  will  be  diminished.  Sea  based 
mines  may  only  be  cleared  by  the  use  of  a  mine  clearing  helicopter  (MCM 
sub-platform)  located  on  the  ships.  Land  mines  may  only  be  cleared 
through  the  use  of  the  engineering  platoon  (ENG  sub-platform). 


Frog  Missile  sites:  These  sites  are  capable  of  launching  short 
range  missiles  containing  chemical  munitions.  The  launchers  take 
approximately  10  minutes  to  set  up.  Suppression  must  be  done  through 
the  use  of  CAS  aircraft  carrying  precision  guided  munitions  located  on  the 
aircraft  carrier,  NSFS,  or  Cobra  attack  helicopter. 

Silkworm  Missile  Site:  The  enemy  has  placed  silkworm  missile 
sites  in  residential  areas  near  the  port.  The  appearance  of  a  silkworm  site 
requires  visual  confirmation  through  use  of  the  Recon  (Tarps  sub- 
platform)  prior  to  attacking  the  site.  The  site  may  only  be  destroyed  by 
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using  CAS  carrying  precision  guided  munitions,  Cobra  attack  helicopters, 
orNSFS. 


Submarines:  The  enemy  submarines  are  Alpha  class  nuclear 
powered  submarines.  They  can  only  be  destroyed  using  the  FFG 
platform. 


Ship:  The  only  ships  the  enemy  possesses  are  fast  patrol  boats. 
These  can  be  destroyed  by  using  either  the  CG,  DDG,  or  CAS  aircraft. 


Helicopter:  The  enemy  possesses  Hind  helicopters  capable  of 
carrying  Exocet  anti-ship  missiles.  The  friendly  asset  capable  of 
destroying  them  are  the  CG,  DDG,  Stinger  detachment  (SD  sub-platform), 
and  fighters  (VF  sub-platform). 


Aircraft:  Enemy  aircraft  may  launch  attacks  against  the  ships. 
Aircraft  may  be  destroyed  by  using  either  the  CG,  DDG,  Stinger 
detachment,  or  fighter  aircraft  located  on  the  carrier. 


Tanks:  Enemy  tanks  may  be  encountered  along  the  road  during  the 
assaults  on  both  the  airfield  and  the  port.  The  tanks  can  only  be  seen 
when  within  the  detection  range  of  friendly  ground  forces.  If  friendly  forces 
move  out  of  range  the  tank  icon  will  disappear.  Tanks  can  only  be 
destroyed  by  using  the  Cobra  attack  helicopters,  CAS  aircraft,  or  NSFS 
from  either  the  DDG  or  CG. 

%/    Unknown  Enemy  Platform:  When  this  icon  appears  it  must  first  be 
identified  to  determine  what  it  is.  The  icon  will  have  a  letter  designation 
followed  by  a "?".  "A"  denotes  unknown  air;  "G"  denotes  unknown  ground; 
and  "S"  denotes  unknown  sea.  The  platform  must  be  identified  with  a 
suitable  friendly  platform  or  sub-platform.  Identification  of  unknown  ground 
platforms  may  only  be  accomplished  using  the  Recon  aircraft  (Tarps  sub- 
platform)  located  on  the  carrier. 


Friendly  Assets 

I I  Friendly  Platform  Icon:  This  icon  is  used  to  represent  friendly 

platforms  in  a  scenario.  The  middle  of  the  box  will  contain  a  letter  to  show 
the  type  of  medium  in  which  the  platform  operates.  The  letter  "G"  denotes 
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a  ground  asset;  the  letter  "S'  denotes  a  sea  asset;  and  the  letter  "A" 
denotes  an  air  asset.  An  additional  letter  and  number  designator  will  be 
shown  on  the  map  above  the  icon  for  further  identification  (i.e.  CVN-01). 
Platform  icons  are  color  coded  to  show  ownership. 


<S> 


Friendly  Sub-platform  Icon:  When  launched  from  its  parent 
platform  a  sub-platform  will  appear  as  a  circle  with  a  letter  and  number 
combination  above  it  for  further  identification  (i.e.  MCM-01).  The  middle  of 
the  circle  will  contain  a  letter  to  show  the  type  of  medium  in  which  the 
platform  operates.  The  letter  "G"  denotes  a  ground  asset;  the  letter  "S' 
denotes  a  sea  asset;  and  the  letter  "A"  denotes  an  air  asset.  Sub-platform 
icons  are  also  color  coded  to  show  ownership. 


El 


Friendly  Platform/Sub-platform  Busy  Icon:  When  a  platform  or 
sub-platform  is  directed  to  perform  some  mission  such  as  attacking; 
transfer  ownership  between  players;  launch  a  sub-platform;  or  when  a 
sub-platform  is  directed  to  return,  the  icon  will  change  to  a  box  with  a  "x"  in 
it.  The  platform  or  sub-platform  cannot  be  directed  to  perform  any  other 
function  until  this  mission  is  completed.  At  the  end  of  the  mission  it  will 
change  back  to  its  previous  form. 


Chain  of  Command 

The  following  organizational  structure  will  be  used  in  the  scenarios. 


CJTG  4.1 


CJTU  4.1.1 


CJTF4 


CJTG  4.2 


CJTG  4.3~| 


CJTU  4.3.1 


CJTF  4:  Overall  commander  of  the  operation  as  delineated  in  the 
oporder.  CJTF  4  commands  the  Recon  tarps  sub-platform  in  the  scenario. 
Units  controlled  by  CJTF  in  a  scenario  will  be  black  in  color. 

CJTG  4.1 :  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Commands  a  LHA,  a  LPD,  and  a  DDG.  ONLY  THE  LPD  WILL  BE 
SHOWN  ON  THE  COMMON  OPERATIONSL  DISPLAY.  ALL  SUB- 
PLATFORMS  WILL  BE  LAUNCHED  FROM  THE  LPD  DURING  GAME 
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PLAY.  Also  commands  two  AH-1  Cobra  sub-platforms,  one  UH-1 
Medivac,  and  one  MH-53  MCM.  Responsible  for  coordination  of  JTU 
4.1 .1  in  attacking  Blue  Beach.  Units  controlled  by  CJTG  4.1  will  be  green 
in  color. 

CJTG  4.2:  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Commands  one  CG,  the  CV,  two  FFGs,  eight  fighter  sections,  and  eight 
CAS  sections.  Units  controlled  by  CJTG  4.2  will  be  blue  in  color. 

CJTG  4.3:  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Commands  a  DDG,  a  LHA,  and  a  LPD.  ONLY  THE  LHA  WILL  BE 
SHOWN  ON  THE  COMMON  OPERATIONAL  DISPLAY.  ALL  SUB- 
PLATFORMS  WILL  BE  LAUNCHED  FROM  THE  LHA  DURING  GAME 
PLAY.  Also  commands  two  AH-1  Cobra  sub-platforms,  one  UH-1 
MEDIVAC,  and  one  MH-53  MCM.  Responsible  for  coordination  of  JTU 
4.3.1  in  attacking  Red  Beach,  commanding  terrain,  and  taking  the  port. 
Units  controlled  by  CJTG  4.3  are  magenta  in  color. 

CJTU  4.1.1:  Reports  directly  to  CJTG  4.1  in  the  chain  of  command. 
Commands  three  rifle  companies,  two  AAAV  mounted  platoons, 
Engineering  platoon  for  land  mine  clearing,  a  Stinger  detachment,  and 
one  MV-22  Osprey  flight. .  One  AAAV  or  one  MV-22  carries  one  rifle 
company  ashore.  Responsible  for  assaulting  Blue  Beach  and  taking  the 
airfield.  Units  controlled  by  CJTU  4.1 .1  will  be  red  in  color. 

CJTU  4.3.1 :  Reports  directly  to  CJTG  4.3  in  the  chain  of  command. 
Commands  three  rifle  companies,  a  AAAV  mounted  platoon,  Engineering 
platoon,  a  Stinger  detachment,  and  two  MV-22  Osprey  flights.  One  AAAV 
or  one  MV-22  carries  one  rifle  company  ashore.  Responsible  for 
assaulting  Red  Beach,  the  commanding  terrain,  and  taking  the  port.  Units 
controlled  by  CJTU  4.3.1  will  be  orange  in  color. 
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Platform 

Owner 

Sub-platform 
(QTY) 

Capability 

Description 

LHA-01 

CJTG4.1 

AH1,  MED1, 
MCM1.MV1 

Large  Deck  amphib  to  support  Blue  Beach 
assault 

LPD-01 

CJTG4.1 

C01,  ENG1, 
SD1,  AAAV1 

Troop  carrier  amphib  to  support  Blue  Beach 
assault 

DDG-01 

CJTG4.1 

NSFS  AAW 

Destroyer 

CVN-02 

CJTG  4.2 

VF,  Recon, 
CAS 

Aircraft  Carrier 

CG-02 

CJTG  4.2 

NSFS  AAW 

Cruiser 

FFG-002A 

CJTG  4.2 

ASW 

Frigate 

FFG-002B 

CJTG  4.2 

ASW 

Frigate 

LHA-03 

CJTG  4.3 

AH3,  MED3, 
MCM3,  MV3 

Large  Deck  amphib  to  support  Red  Beach 
assault 

LPD-03 

CJTG  4.3 

C03,  ENG3, 
SD3,  AAAV3 

Troop  carrier  amphib  to  support  Red  Beach 
assault 

DDG-03 

CJTG  4.3 

NSFS  AAW 

Destroyer 

Sub- 
Platform 

Owner 

Location 

Quantity 

Capability 

Recon 

CJTF4 

CVN-02 

1 

F-14  Tarps  for  Recon  only 

AH1 

CJTG  4.1 

LHA-01 

2 

Cobra  Attack  Helicopter 

MED1 

CJTG  4.1 

LHA-01 

1 

UH-1  Medivac 

MCM 

CJTG  4.1 

LHA-01 

1 

Helicopter  for  clearing  sea  based  mines 

VF 

CJTG  4.2 

CVN-02 

8 

F-14fighersforCAP 

CAS 

CJTG  4.2 

CVN-02 

8 

F/A-18  equiped  with  precision  guided  munitions 

AH3 

CJTG  4.3 

LHA-03 

2 

Cobra  Attack  Helicopter 

MED3 

CJTG  4.3 

LHA-03 

1 

UH-1  Medivac 

MCM3 

CJTG  4.3 

LHA-03 

1 

Helicopter  for  clearing  sea  based  mines 

COI 

CJTU  4.1.1 

LPD-01 

3 

Rifle  Companies 

AAAV1 

CJTU  4.1.1 

LPD-01 

2 

AAAV  mounted  platoon 

ENG1 

CJTU  4.1.1 

LPD-01 

1 

Engineering  platoon  for  clearing  land  mines 

SD1 

CJTU  4.1.1 

LPD-01 

1 

Stinger  Detachment  for  Anti-Air  Defense 

MV1 

CJTU  4.1.1 

LHA-01 

1 

MV-22  Osprey 

C03 

CJTU  4.3.1 

LPD-03 

3 

Rifle  Companies 

AAAV3 

CJTU  4.3.1 

LPD-03 

1 

AAAV  mounted  platoon 

ENG3 

CJTU  4.3.1 

LPD-03 

1 

Engineering  platoon  for  clearing  land  mines 

SD3 

CJTU  4.3.1 

LPD-03 

1 

Stinger  Detachment  for  Anti-Air  Defense 

MV3 

CJTU  4.3.1 

LHA-03 

2 

MV-22  Osprey 
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DDD  Tutorial 


The  DDD  Graphical  User  interface 

The  DDD  graphical  user  interface  displays  a  map  on  the  left  side  of 
the  screen  which  is  a  graphical  representation  of  friendly  and  enemy 
platforms.  Within  the  map,  land  is  represented  by  squares  which  have  a 
brown  tint,  and  sea  by  squares  which  are  white.  The  mouse  commands 
listed  in  the  next  section  will  describe  how  friendly  platforms  on  the  map 
may  be  manipulated  and  how  information  on  enemy  platforms  is  obtained. 
The  right  half  of  the  screen  contains  four  buttons: 

Start/Refresh:  The  Start  button  is  used  only  at  the  beginning  of  a  scenario  to 

start  all  of  the  stations  playing.  Once  the  scenario  has  begun,  the  button 

changes  to  Refresh.  Left  clicking  on  the  Refresh  button  redraws  the  map 

eliminating  any  undesired  traces  which  may  appear. 

Zoom  In:  Allows  the  user  to  zoom  in  for  a  more  detailed  look  at  a  particular 

section  of  the  map.  To  zoom  in,  left  click  on  the  "Zoom  In"  button.  Move  the 

cursor  over  to  map  and  left  click  at  a  point  to  the  left  or  right  of  where  the 

area  of  interest  lies.  While  continuing  to  hold  the  left  mouse  button 

depressed,  drag  the  cursor  and  a  box  will  begin  to  appear  showing  the  area 

which  will  be  zoomed  in  on. 

Zoom  Out:  Left  clicking  on  this  button  returns  the  map  to  the  previous  map 

size. 

Cancel:  Left  Clicking  on  the  Cancel  button  allows  the  user  to  suspend  an 

operation  on  an  asset  such  as  a  move  or  an  attack  prior  to  completing  the 

mission. 

The  right  half  of  the  screen  also  contains  a  time  bar.  When  a 
friendly  platform  or  sub-platform  is  selected  to  perform  an  action  (i.e. 
launch  aircraft,  attack),  a  white  arrow  will  appear  next  to  this  bar  showing 
the  amount  of  time  to  complete  this  mission.  The  platform  cannot  perform 
any  other  action  until  this  action  is  completed.  In  addition,  above  the  time 
bar  are  several  other  pieces  of  information.  The  color  of  the  stick  man 
figure  in  a  box  shows  the  color  of  the  platforms  on  the  map  which  your 
station  controls.  Next  to  this  box  is  the  name  of  the  station  you  are  playing 
(i.e.  CJTF  4,  CJTG  4.1 ,  etc.)  Below  the  box  are  two  counters  which 
display  feedback  on  how  well  the  entire  team  is  doing  on  the  scenario. 
The  counter  labeled  mission  starts  at  zero  and  increments  as  missions 
are  accomplished.  The  counter  labeled  strength  starts  at  100  and 
decrements  as  your  force  strength  is  decreased. 

The  lower  portion  of  the  screen  contains  two  window  dialog  boxes. 
Close  attention  must  be  given  to  the  window  on  the  left  as  this  box 
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displays  messages  between  the  various  players  which  may  require  some 
action  to  be  taken  by  your  station.  The  right  window  can  best  be  described 
as  a  confirmation  window.  Summaries  of  messages  or  actions  performed 
by  your  station  will  appear  in  this  window  along  with  some  messages 
about  the  status  of  other  friendly  platforms.  Also,  the  very  bottom  of  the 
screen  below  these  two  windows  displays  warning  and  error  prompts.  A 
beep  will  occur  along  with  a  warning  or  error  message  following  any  action 
performed  by  your  station  which  is  not  allowed  (i.e.  Attempting  to  attack 
the  enemy  when  your  unit  is  out  of  range). 


Using  the  Mouse  in  DDD 

A  standard  three  button  mouse  is  used  when  running  a  scenario  at 
each  workstation.  When  clicking  on  an  platform  in  DDD  each  mouse 
button  serves  a  different  function  depending  on  whether  the  platform  is 
friend  or  foe,  and  if  friend  whether  or  not  the  platform  is  owned  or  not 
owned  by  you. 

Left  Mouse  Button 

The  left  mouse  button  clicked  on  an  platform  will  just  select  it.  The 
left  mouse  button  is  also  used  to  carry  out  options  from  a  Right  Mouse 
Menu  covered  on  the  next  page. 

Middle  Mouse  Button 

When  the  middle  button  is  clicked  on  an  platform,  the  window 
presented  depends  on  whether  the  platform  is  a  (1)  friendly  platform  or 
sub-platform  or  (2)  enemy  platform.  If  the  platform  is  an  enemy  platform  , 
a  window  appears  which  provides  known  information  about  the  attributes 
of  the  platform.  If  a  friendly  platform  is  selected,  a  screen  appears  which 
displays  the  attributes  of  that  platform  or  sub-platform.  A  friendly  platform 
will  show  the  attributes,  ownership,  and  the  number  of  all  sub-platforms 
located  on  the  platform  is  also  shown.  (Platforms  are  the  major  friendly 
platforms  in  the  scenarios.  Sub-platforms  are  platforms  such  as  aircraft, 
Stinger  detachments,  engineering  platoons,  helicopters,  etc.  which  are 
carried  by  a  platform.  The  ownership  of  any  sub-platform  may  or  may  not 
be  the  same  as  the  owner  of  the  platform  it  is  being  carried  on). 

When  a  friendly  platform  is  selected  with  the  middle  mouse  button, 
the  portion  of  the  window  where  the  sub-platforms  are  listed  is  used  to 
launch  or  request  launch  of  a  sub-platform  depending  on  where  the  sub- 
platform  is  located.  There  are  three  possible  situations  which  can  occur 
here: 
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1 .  Sub-platform  needed  to  be  launched  is  on  a  platform  owned  by  vou:  In  this 
case  you  can  launch  any  sub-platform  on  your  platform  whether  you  own  it  or 
not.  This  is  done  by  left  clicking  on  the  right  arrow  key  in  the  line  for  the 
number  of  sub-platform(s)  needed  and  then  clicking  OK. 

2.  Sub-platform  needed  to  be  launched  is  owned  by  vou.  but  is  located  on  a 
platform  which  vou  do  not  own: 

a)  In  this  case  middle  click  on  the  platform  where  your  sub-platform  is 
located. 

b)  Left  click  on  the  arrow  located  in  the  line  of  the  sub-platform 
needed  until  the  desired  number  of  sub-platforms  to  be  launched  is 
set 

c)  Left  click  on  OK.  A  message  will  then  be  sent  to  the  owner  of  the 
platform  where  your  sub-platform  is  located  requesting  that  it  be 
launched.  It  is  the  responsibility  of  the  person  where  your  sub- 
platform  resides  to  launch  it. 

1.   Sub-platform  needed  is  not  owned  by  vou  and  is  located  on  a  platform  not 
owned  by  vou:  In  this  case  middle  click  on  the  platform  where  the  sub- 
platform  needed  resides.  Left  click  on  the  arrow  on  the  line  containing  the 
sub-platform  desired  until  the  required  number  is  set,  and  then  left  click  on 
OK.  A  message  will  then  be  forwarded  up  your  chain  of  command  which  must 
be  acted  upon  by  your  immediate  superior  to  obtain  this  sub-platform. 

The  lower  portion  of  this  screen  also  offers  options  for  displaying 
information  on  range  for  both  sensors  and  weapons  of  a  friendly  platform 
against  enemy  ground,  air,  or  sea  assets.  The  sensor  option  will  display 
four  range  rings  around  the  platform: 

1 )  The  outermost  black  ring  represents  the  detection  range. 

2)  The  next  inner  black  ring  represents  the  range  at  which  measurements 
on  the  enemy  can  be  made. 

3)  The  furthest  inner  black  ring  represents  the  visual  detection  range. 

4)  The  inner  yellow  ring  represents  the  range  at  which  the  platform  is 
vulnerable. 


The  weapons  option  displays  a  single  red  ring  around  the  platform 
which  shows  the  effective  range  of  its  weapon.  To  display  these  range 
rings  left  click  on  either  sensors,  weapon,  or  both,  and  then  left  click  what 
type  of  medium  to  display  these  for  (air,  ground,  or  sea).  To  turn  the  range 
rings  off,  middle  click  on  the  platform  and  left  click  on  none. 

Right  Mouse  Button 
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The  right  mouse  button  will  cause  a  menu  to  pop  up.  The  following 
sections  describe  the  options  presented  depending  on  the  platform 
selected  with  the  right  mouse  button. 

Friendly  platform  which  you  do  not  own:  The  menu  that  pops  up  will 
present  the  option  of  requesting  the  asset,  forcing  the  transfer  of  the 
asset,  or  information  on  the  asset.  Explanations  of  these  options  follow: 

Request  (REQ):  The  menu  requires  input  for  who  the  request  is  to,  and  the 
urgency  of  the  request.  All  items  must  be  selected.  When  the  choices  are 
completed,  a  message  is  sent  to  the  person  selected  if  they  are  directly  in 
your  chain  of  command  or  up  your  chain  of  command  where  your  superior 
must  take  action  on  the  request. 

Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

Friendly  platform  which  you  own:  This  menu  will  allow  the  choices  of 
Move,  Pursue,  Attack,  Return,  Transfer,  or  Information.  An  explanation  of 
these  options  follow: 

Move:  Selecting  move  will  cause  a  cross-hair  type  symbol  to  appear.  Position 
this  cross  hair  to  the  place  the  platform  is  desired  to  be  moved  and  single 
click  with  the  left  mouse  button.  The  platform  will  then  move  to  this  position. 
When  it  arrives  there,  it  will  stop  until  another  command  to  move  is  given. 

•  Pursue:  Selecting  pursue  will  cause  the  cursor  to  change  to  a  finger.  Place 
the  finger  on  the  enemy  platform  desired  to  be  pursued,  left  click,  and  your 
platform  will  then  move  to  pursue  it. 

•  Attack:  When  this  option  is  selected  a  question  mark  will  appear.  Place  the 
question  mark  on  the  platform.  If  in  range  to  perform  this  action,  a  menu  will 
then  appear  which  shows  the  attributes  of  the  platform  selected  to  perform 
the  attack  and  the  attributes  of  the  platform  that  the  attack  is  to  be  performed 
on.  The  option  is  then  given  to  carry  out  the  mission  or  to  cancel  the 
assignment. 

•  Coordinated  Attack:  If  the  platform  selected  to  attack  the  enemy  does 
not  have  enough  combat  power  to  accomplish  the  mission,  a  coordinated  attack 
may  be  performed.  It  should  be  noted  that  the  following  explanations  of  how  to 
do  a  coordinated  attack  will  work  only  if  all  of  the  platforms  are  within  attack 
range. 

•  Coordinated  Attack  using  Two  Platforms:  A  coordinated  attack  using 
two  platforms  is  accomplished  by  first  selecting  one  of  the  two  platforms  to 
perform  the  coordinated  attack  with  the  left  mouse  button,  and  then  right  clicking 
on  the  second  platform  performing  the  attack.  The  menu  will  then  pop  up  and 
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select  the  attack  option.  The  cursor  will  then  change  to  the  question  mark.  Place 
it  on  the  platform  which  is  to  be  attacked  and  left  click  with  the  mouse. 

•  Coordinated  Attack  using  Three  or  More  Platforms:  To  perform  a 
coordinated  attack  with  three  or  more  platforms,  left  click  on  the  first  platform 
performing  the  attack.  Then,  while  holding  the  shift  key  down  on  the  keyboard, 
left  click  on  all  but  one  of  the  remaining  platforms  performing  the  attack. 
Release  the  shift  key  and  right  click  on  the  final  platform.  The  menu  will  pop  up 
and  select  attack.  The  cursor  will  change  to  a  question  mark.  Place  it  on  the 
platform  to  be  attacked  and  left  click. 

A  simultaneous  attack  by  two  or  more  players  may  be  needed  to  bring 
sufficient  combat  power  to  bear.  These  should  be  coordinated  using  the  voice 
net. 

•  Return:  This  option  may  only  be  used  for  sub-platforms.  Selecting  this  option 
will  cause  the  sub-platform  to  return  to  the  platform  it  originated  from.  The 
sub-platform  will  not  move  towards  its  originating  platform,  but  instead  will 
change  to  a  box  with  a  "x"  in  it  to  simulate  returning  to  its  originating  platform. 
The  return  option  has  been  disabled  on  some  sub-platforms  in  the  scenario. 
If  one  of  these  sub-platforms  is  directed  to  return,  an  error  message  will 
appear. 

•  Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

Enemy  Platforms:  The  menu  presented  in  this  instance  presents  the 
options  of  Identify,  Requesting  Information,  Transferring  Information, 
Coordinating  Action,  Assigning,  and  Information.  Explanations  of  these 
options  follow: 

•  Identify:  This  option  is  normally  used  to  identify  enemy  platforms  or  s  for 
which  the  identity  is  unknown.  This  will  be  readily  apparent  in  a  scenario  as 
the  first  letter  shown  with  the  icon  will  be  followed  by  a  question  mark.  The 
first  letter  designates  which  medium  the  unknown  contact  operates  in.  "A?" 
denotes  an  unknown  air  contact;  "G?"  denotes  an  unknown  ground  contact; 
"S?"  denotes  an  unknown  sea  contact.  Selecting  the  identify  option  will  cause 
a  menu  to  pop  up  which  shows  the  known  attributes  of  the  platform  as  seen 
by  each  player  in  the  scenario.  If  a  friendly  platform  having  sensors  capable 
of  identifying  the  enemy  platform  is  within  sensor  range  the  platform  will  be 
identified  correctly.  If  not,  the  question  mark  will  remain.  This  will  be  apparent 
by  looking  at  the  lower  left  hand  column  where  the  identity  will  be  shaded 
from  a  list  of  possible  identities.  Click  the  fused  button  near  the  top  left  hand 
corner  and  then  OK.  The  identity  of  the  platform  will  then  appear  correctly  on 
the  map  and  its  icon  will  change  to  its  correct  identity. 
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The  following  tables  give  descriptions  of  the  two  letter  symbols  which  will  be 
the  options  shown  when  identifying  an  platform: 


Unknown  Ground 

Description 

9 

ynkngwn 

HL 

Ground  mission  of  takina  a  hill 

AP 

Airport  around  mission 

SP 

Seaport  around  mission 

HD 

Holdina  or  occuovina  around 

TK 

Takinq  a  qround  mission 

AT 

Enemy  artillery 

FG 

Enemy  Froq  launcher 

SWG 

Enemy  Silkworm  missile  launcher 

TN 

Enemy  tanks,  troops,  or  vehicles 

NU 

Neutral 

MN 

Land  Mines 

Unknown  Air 

Description 

? 

Unknown 

AS 

Enemy  attack  aaainst  ships 

AG 

Enemy  attack  aaainst  around  forces 

HH 

Enemy  helo  attack  aaainst  ships 

NU 

Neutral 

SWA 

Silkworm  missile  in  fliaht 

Unknown  Sea 

Description 

? 

Unknown 

MS 

$ea  mines 

P? 

Enemy  patrol  boats 

SS 

Enemy  submarines 

ML 

Enemy  anti-ship  cruise  missiles 

NU 

Neutral 

Request  Information  (REQ  INFO):  Selecting  this  option  will  cause  a  menu  to 
pop  up  which  allows  you  to  select  an  other  player,  or  all  other  players  from 
whom  you  wish  to  obtain  information  on  the  enemy  platform.  Select  the 
person(s)  and  click  OK.  A  message  will  then  be  sent  to  the  person(s) 
notifying  them  that  this  information  is  requested. 

Transfer  Information  (XFR  INFO):  Selecting  this  option  will  cause  a  menu 
to  pop  up  which  allows  you  to  select  a  particular  individual,  or  all  the  players 
you  wish  information  on  the  enemy  platform  to  be  sent  to  .  Select  the 
person(s)  and  click  OK.  A  message  will  then  be  sent  to  the  person(s) 
selected. 

Coordinate  Action  (CRD  ACTION):  The  use  of  this  option  allows  messages 
to  be  sent  between  players  concerning  action  requests,  support,  or  intent 
against  an  enemy  platform.  When  selected,  a  menu  pops  up  displaying 
options  for  choosing  who  the  message  is  to  sent  to  and  a  list  of  messages 
which  may  be  sent.  The  following  messages  may  be  sent: 

1 .  I  plan  to  handle. 

2.  I  plan  to  support. 

3.  I  cannot  handle. 

4.  I  cannot  support. 

5.  Can  you  handle  ? 

6.  Can  you  support  ? 

Select  the  person  the  message  is  to  be  sent  to,  a  message  is  to  be  sent,  and 
click  OK.  The  message  will  then  be  sent  to  the  person  selected. 

Assign:  This  option  may  only  be  used  if  you  are  playing  a  position  where 
you  are  superior  to  someone  in  the  chain  of  command  and  may  only  be 
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directed  at  those  people  who  are  subordinate  to  you.  This  option  will  cause  a 
question  mark  to  appear.  Place  it  on  the  enemy  platform  desired  to  be 
assigned  and  left  click.  A  menu  will  then  appear  which  allows  selecting  whom 
in  the  chain  of  command  it  is  to  be  assigned  to.  Left  click  on  the  person 
desired  to  assign  the  mission  to  and  click  OK.  A  message  will  then  be  sent  to 
that  person  notifying  them  they  are  responsible  for  taking  care  of  the  mission. 

Information  (INFO):  Same  as  middle  clicking  on  the  platform. 

List  of  Platforms  in  the  Scenario 

Terrain  and  task  platforms 

The  following  shows  representations  of  the  icons  which  represents 
terrain  or  task  platforms  in  the  scenarios. 


± 


Swamp:  The  swamp  icon  indicates  areas  which  mechanized  or 
infantry  units  should  not  traverse.  Friendly  units  will  not  be  destroyed  by 
going  into  these  areas,  but  total  strength  will  be  diminished. 

IFtI     Airfield:  The  airfield  icon  is  the  objective  or  mission  to  completed 
by  CJTG  4.3.  This  airfield  has  attributes  associated  with  it  which  must  be 
compared  to  the  attacking  force  attributes  to  determine  if  the  necessary 
force  is  available. 

Ff-  ot^tfI  Port:  The  port  is  the  objective  or  mission  of  CJTG  4.1 .  It, 
like  the  airfields,  also  has  attributes  which  must  first  be  determined  and 
compared  to  attacking  forces  attributes  to  determine  if  enough  combat 
power  can  be  brought  to  bare  to  achieve  this  objective. 


/h 


Hill:  The  hill  is  commanding  terrain  between  the  port  and  airfield 
which  must  be  captured  by  CJTU  4.1.  It  is  surrounded  by  swamps  on  both 
sides  which  means  the  only  way  of  accomplishing  this  mission  is  by  using 
the  AAAV  or  MV-22  sub-platforms. 

■      Task:  The  task  icon  has  attributes  which  must  first  be  identified  and 
then  a  determination  made  as  to  the  best  asset  available  to  complete  this 
task.  Tasks  are  normally  used  to  represent  enemy  ground  forces  in  a 
given  location  which  must  be  eliminated. 

Medivac:  The  medivac  icon  is  a  mission  which  may  appear  after 
friendly  ground  platforms  or  sub-platforms  engage  enemy  platforms  .  The 
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task  has  attributes  which  must  be  determined.  The  mission  is  completed 
by  attacking  it  with  the  medivac  helicopter  (MED  sub-platform). 


'B"*°'~E>'Hold:  The  hold  icon  may  appear  after  completion  of  a  mission 
(i.e.  attacking  the  hill).  If  this  occurs  the  asset  used  to  perform  the  mission 
must  remain  in  its  current  position  and  may  not  be  used  to  perform  any 
other  mission. 

Enemy  Assets 

The  following  section  shows  the  icons  which  represent  enemy 
forces  that  may  or  may  not  appear  in  a  scenario.  The  text  which  follows 
each  icon  describes  the  enemy  platforms  capabilities  and  the  friendly 
weapon  of  choice  to  use  against  it. 

J^.  Artillery:  Enemy  artillery  pieces  may  pop  up  at  various  times. 
When  they  appear,  they  take  approximately  5  minutes  to  set  up  before 
they  are  able  to  fire.  The  pieces  are  stored  in  reinforced  concrete  bunkers 
with  the  ammunition  stored  in  deep  underground  bunkers.  The  methods 
by  which  enemy  artillery  may  be  suppressed  is  through  the  use  of  Naval 
Surface  Fire  support  (NSFS),  Close  Air  Support  (CAS),  or  Cobra  attack 
helicopter.    NSFS  can  be  accomplished  by  either  the  DDG  or  CG.  Once 
the  artillery  pieces  begin  to  move  toward  you,  which  simulates  firing,  you 
will  be  unable  to  attack  them. 


-O- 


Mines:  The  enemy  possesses  the  possibility  of  deploying  both 
land  and  sea  mines.  If  encountered  and  moved  through  by  friendly  forces 
the  total  effectiveness  of  these  forces  will  be  diminished.  Sea  based 
mines  may  only  be  cleared  by  the  use  of  a  mine  clearing  helicopter  (MCM 
sub-platform)  located  on  the  ships.  Land  mines  may  only  be  cleared 
through  the  use  of  the  engineering  platoon  (ENG  sub-platform). 


Frog  Missile  sites:  These  sites  are  capable  of  launching  short 
range  missiles  containing  chemical  munitions.  The  launchers  take 
approximately  10  minutes  to  set  up.  Suppression  must  be  done  through 
the  use  of  CAS  aircraft  carrying  precision  guided  munitions  located  on  the 
aircraft  carrier,  NSFS,  or  Cobra  attack  helicopter. 

Silkworm  Missile  Site:  The  enemy  has  placed  silkworm  missile 
sites  in  residential  areas  near  the  port.  The  appearance  of  a  silkworm  site 
requires  visual  confirmation  through  use  of  the  Recon  (Tarps  sub- 
platform)  prior  to  attacking  the  site.  The  site  may  only  be  destroyed  by 
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using  CAS  carrying  precision  guided  munitions,  Cobra  attack  helicopters, 
orNSFS. 


Submarines:  The  enemy  submarines  are  Alpha  class  nuclear 
powered  submarines.  They  can  only  be  destroyed  using  the  FFG 
platform. 


Ship:  The  only  ships  the  enemy  possesses  are  fast  patrol  boats. 
These  can  be  destroyed  by  using  either  the  CG,  DDG,  or  CAS  aircraft. 


Helicopter:  The  enemy  possesses  Hind  helicopters  capable  of 
carrying  Exocet  anti-ship  missiles.  The  friendly  asset  capable  of 
destroying  them  are  the  CG,  DDG,  Stinger  detachment  (SD  sub-platform), 
and  fighters  (VF  sub-platform). 


Aircraft:  Enemy  aircraft  may  launch  attacks  against  the  ships. 
Aircraft  may  be  destroyed  by  using  either  the  CG,  DDG,  Stinger 
detachment,  or  fighter  aircraft  located  on  the  carrier. 


Tanks:  Enemy  tanks  may  be  encountered  along  the  road  during  the 
assaults  on  both  the  airfield  and  the  port.  The  tanks  can  only  be  seen 
when  within  the  detection  range  of  friendly  ground  forces.  If  friendly  forces 
move  out  of  range  the  tank  icon  will  disappear.  Tanks  can  only  be 
destroyed  by  using  the  Cobra  attack  helicopters,  CAS  aircraft,  or  NSFS 
from  either  the  DDG  or  CG. 

\/    Unknown  Enemy  Platform:  When  this  icon  appears  it  must  first  be 
identified  to  determine  what  it  is.  The  icon  will  have  a  letter  designation 
followed  by  a "?".  "A"  denotes  unknown  air;  "G"  denotes  unknown  ground; 
and  "S"  denotes  unknown  sea.  The  platform  must  be  identified  with  a 
suitable  friendly  platform  or  sub-platform.  Identification  of  unknown  ground 
platforms  may  only  be  accomplished  using  the  Recon  aircraft  (Tarps  sub- 
platform)  located  on  the  carrier. 


Friendly  Assets 

I I  Friendly  Platform  Icon:  This  icon  is  used  to  represent  friendly 

platforms  in  a  scenario.  The  middle  of  the  box  will  contain  a  letter  to  show 
the  type  of  medium  in  which  the  platform  operates.  The  letter  "G"  denotes 
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a  ground  asset;  the  letter  "S*  denotes  a  sea  asset;  and  the  letter  "A" 
denotes  an  air  asset.  An  additional  letter  and  number  designator  will  be 
shown  on  the  map  above  the  icon  for  further  identification  (i.e.  CVN-01). 
Platform  icons  are  color  coded  to  show  ownership. 


<B> 


Friendly  Sub-platform  Icon:  When  launched  from  its  parent 
platform  a  sub-platform  will  appear  as  a  circle  with  a  letter  and  number 
combination  above  it  for  further  identification  (i.e.  MCM-01).  The  middle  of 
the  circle  will  contain  a  letter  to  show  the  type  of  medium  in  which  the 
platform  operates.  The  letter  "G"  denotes  a  ground  asset;  the  letter  "S' 
denotes  a  sea  asset;  and  the  letter  "A"  denotes  an  air  asset.  Sub-platform 
icons  are  also  color  coded  to  show  ownership. 


ISI 


Friendly  Platform/Sub-platform  Busy  Icon:  When  a  platform  or 
sub-platform  is  directed  to  perform  some  mission  such  as  attacking; 
transfer  ownership  between  players;  launch  a  sub-platform;  or  when  a 
sub-platform  is  directed  to  return,  the  icon  will  change  to  a  box  with  a  "x"  in 
it.  The  platform  or  sub-platform  cannot  be  directed  to  perform  any  other 
function  until  this  mission  is  completed.  At  the  end  of  the  mission  it  will 
change  back  to  its  previous  form. 


Chain  of  Command 

The  following  organizational  structure  will  be  used  in  the  scenarios. 


CJTG  4.1 


CJTF4 


1 


CJTG  4.2 


CJTG  4.3"] 


CJTU  4.2.1 


CJTU  4.2.2 


] 
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CJTF  4:  Overall  commander  of  the  operation  as  delineated  in  the 
oporder.  CJTF  4  commands  the  aircraft  carrier,  CAS  aircraft,  and  Recon 
tarps  sub-platform  in  the  scenario.  Units  controlled  by  CJTF  in  a  scenario 
will  be  black  in  color. 

CJTG  4.1 :  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Commands  three  rifle  companies,  a  LHA,  and  a  LPD.  ONLY  THE  LPD 
WILL  BE  SHOWN  ON  THE  COMMON  OPERATIONSL  DISPLAY.  ALL 
SUB-PLATFORMS  WILL  BE  LAUNCHED  FROM  THE  LPD  DURING 
GAME  PLAY.  Also  commands  a  AAAV  mounted  platoon,  two  MV-22 
flights,  and  a  Stinger  Detachment.  One  AAAV  or  one  MV-22  carries  one 
rifle  company  ashore.  Responsible  for  attacking  Red  Beach,  commanding 
terrain,  and  taking  the  Port.  Units  controlled  by  CJTG  4.1  will  be  green  in 
color. 

CJTG  4.2:  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Responsible  for  the  detachment  of  two  AH-1  Cobras.  CJTG  4.2  will 
coordinate  the  actions  of  CJTU  4.2.1  and  CJTU  4.2.2.  Units  controlled  by 
CJTG  4.2  will  be  blue  in  color. 

CJTG  4.3:  Reports  directly  to  CJTF  4  in  the  chain  of  command. 
Commands  three  rifle  companies,  a  LHA,  and  a  LPD.  ONLY  THE  LHA 
WILL  BE  SHOWN  ON  THE  COMMON  OPERATIONAL  DISPLAY.  ALL 
SUB-PLATFORMS  WILL  BE  LAUNCHED  FROM  THE  LHA  DURING 
GAME  PLAY.  Also  commands  two  AAAV  mounted  platoons,  a  MV-22 
flight,  a  Stinger  detachment,  and  two  AH-1  Cobra  attack  helicopters.  . 
One  AAAV  or  one  MV-22  carries  one  rifle  company  ashore.  Responsible 
for  attacking  Blue  Beach  and  taking  the  airfield.  Units  controlled  by  CJTG 
4.3  are  magenta  in  color. 

CJTU  4.2.1:  Reports  directly  to  CJTG  4.2  in  the  chain  of  command. 
Commands  two  DDGs  and  the  CG.  Additionally  commands  an 
Engineering  platoon,  a  MH-53  MCM,  and  a  UH-1  MEDIVAC. 
Responsible  for  assisting  CJTG  4.1  and  CJTG  4.3  in  the  assault.  Units 
controlled  by  CJTU  4.1.1  will  be  red  in  color. 

CJTU  4.3.1 :  Reports  directly  to  CJTG  4.2  in  the  chain  of  command. 
Commands  two  FFGs  and  8  sections  of  fighters  for  CAP.  Additionally 
commands  an  Engineering  platoon,  a  MH-53  MCM,  and  a  UH-1 
MEDICAC.  Responsible  for  ASW  and  supporting  CJTG  4.1  and  CJTG 
4.3  in  the  assault.  Units  controlled  by  CJTU  4.3.1  will  be  orange  in  color. 
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Platform 

Owner 

Sub-platform  (QTY) 

Capability 

Description 

CVN-01 

CJTF4 

Recon,  VF,  CAS 

Aircraft  Carrier 

LHA-01 

CJTG  4.1 

AH1.MED1,  MCM1.MV1 

Large  Deck  amphib  to  support  Red 
Beach  assault 

LPD-01 

CJTG4.1 

C01.ENG1.SD1,  AAAV1 

Troop  carrier  amphib  to  support 
Red  Beach  assault 

LHA-03 

CJTG  4.3 

AH3,  MED3,  MCM3,  MV3 

Large  Deck  amphib  to  support  Blue 
Beach  assault 

LPD-03 

CJTG  4.3 

C03,  ENG3,  SD3,  AAAV3 

Troop  carrier  amphib  to  support 
Blue  Beach  assault 

DDG-01A 

CJTU  4.2.1 

NSFS  AAW 

Destroyer 

DDG-01B 

CJTU  4.2.1 

NSFS  AAW 

Destroyer 

CG-01 

CJTU  4.2.1 

NSFS  AAW 

Cruiser 

FFG-02A 

CJTU  4.2.2 

ASW 

Frigate 

FFG-02B 

CJTU  4.2.2 

ASW 

Frigate 

Sub-Platform 

Owner 

Location 

Quantity 

Capability 

Recon 

CJTF4 

CVN-01 

1 

F-14  Tarps  for  Recon  only 

CAS 

CJTF4 

LHA-01 

8 

F/A-18  equiped  with  precision 
guided  munitions 

C01 

CJTG  4.1 

LPD-01 

3 

Rifle  Companies 

AAAV1 

CJTG  4.1 

LPD-01 

1 

AAAV  mounted  platoon 

MV1 

CJTG  4.1 

LHA-01 

2 

MV-22  Osprey 

SD1 

CJTG  4.2 

LPD-01 

1 

Stinger  Detachment  for  Anti-Air 
Defense 

AH1 

CJTG  4.2 

LHA-01 

2 

Cobra  Attack  Helicopter 

C03 

CJTG  4.3 

LPD-03 

3 

Rifle  Companies 

AAAV3 

CJTG  4.3 

LPD-03 

2 

AAAV  mounted  platoon 

MV3 

CJTG  4.3 

LHA-03 

1 

MV-22  Osprey 

SD3 

CJTG  4.3 

LPD-01 

1 

Stinger  Detachment  for  Anti-Air 
Defense 

AH3 

CJTG  4.3 

LHA-03 

2 

Cobra  Attack  Helicopter 

ENG1 

CJTU  4.2.1 

LPD-01 

1 

Engineering  platoon  for  clearing 
land  mines 

MCM1 

CJTU  4.2.1 

LHA-01 

1 

Helicopter  for  clearing  sea  based 
mines 

MED1 

CJTU  4.2.1 

LHA-01 

1 

UH-1  MEDIVAC 

VF 

CJTU  4.2.2 

CVN-01 

8 

F-14  fighters  for  CAP 

ENG3 

CJTU  4.2.2 

LPD-03 

1 

Engineering  platoon  for  clearing 
land  mines 

MCM3 

CJTU  4.2.2 

LHA-03 

1 

Helicopter  for  clearing  sea  based 
mines 

MED3 

CJTU  4.2.2 

LHA-03 

1 

UH-1  MEDIVAC 
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APPENDIX  B.  DATA  COLLECTION  FORMS  AND  QUESTIONAIRES 

Appendix  B  contains  the  forms  used  during  the  DDD-ETI  runs  and  the  planning  sessions  to 
record  observations  and  the  results  of  the  players  planning  sessions  and  the  questionaires  the 
players  were  asked  complete  at  the  end  of  the  trials. 

Player  Questionaire   154 

A2C2  Post-Planning  Assessment:  Observer  Rating  Form    157 

A2C2  Planning  Organizer  and  Products  Booklet    159 
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A2C2  EXPERIMENT  POST-PLANNING  QUESTIONAIRE 

Name: Position: 


Team  ID: Planning  Session: Date:. 


This  questionaire  is  comprised  of  three  parts.  The  first  part  asks  you  to  speculate  about 
changes  that  would  be  required  in  the  organization  and  architecture  you  designed  if  different 
priorities  were  in  effect.  The  second  part  asks  you  to  rate  several  attributes  of  high  priority  tasks. 
The  third  part  inquires  about  aspects  of  the  planning  and  designing  products. 

PART  I:  Different  Priorities 

1 .  If  you  were  instructed  to  plan  and  design  your  organization  and  architecture  to  cope  with  a 
very  short  time  period  and  minimize  the  amount  of  time  necessary  to  accomplish  the  revised 
mission  after  the  event,  what  changes  would  you  make  to  the  organization  and  architecture  you 
devise?  Describe  these  changes  (if  any)  briefly. 


2.  What  if  you  were  asked  to  minimize  the  amount  of  assets  and  resources  needed  to  complete 
the  mission,  what  changes  would  you  make  to  the  organization  and  architecture  you  devise? 
Describe  these  changes  (if  any)  briefly. 


3.  What  if  you  were  asked  to  minimize  the  amount  of  risk  involved  in  the  operation,  what 
changes  would  you  make  to  the  organization  and  architecture  you  devise?  Describe  these  changes 
(if  any)  briefly. 
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PART  2:  Attributes  of  Hi  eh  Priority  Tasks 

examine  the  plan  you  have  just  completed  and  select  the  three  (3)  highest  priority  (i.e. 
most  critical)  tasks  that  must  be  completed  to  accomplish  the  mission.  Write  a  descriptive  name 
for  the  highest  priority  task  under  Task  1,  the  next  highest  priority  task  under  Task  2,  etc.  Some 
tasks  require  a  short  amount  of  time  to  complete,  but  their  execution  is  critical  to  the  mission. 
Other  tasks  are  important  because  they  demand  a  great  deal  of  time  to  complete.  Still  other  tasks 
are  not  critical  unless  they  are  not  done,  then  they  become  very  critical  because  terrible  things  can 
happen.  Consider  the  different  reasons  the  tasks  you  selected  are  critical  and  rate  each  of  these 
tasks  on  the  scales  below. 


Taskl 

Task  2 

Task  3 

Time  spent  -  The  amount  of  time  spent,  relative  to  other  tasks  in  the  mission. 

I       I       I      I       I        I 
a  little                             a  lot 

I      I      I      I      I       I 

a  little                            a  lot 

I      I      I      I 
a  little 

I       I 
a  lot 

Task  difficulty  -  How  difficult  it  is  to  perform  the  task,  relative  to  all  other  tasks  in  the  mission. 

I       I       I      I       I        I 

a  little                            a  lot 

I      I      I      I      I       I 
a  little                            a  lot 

I      I      I      I 
a  little 

I       I 

a  lot 

Task  criticality  -  Degree  to  which  incorrect  performance  of  the  task  would  result  in  negative  consequences. 

I       I       I      I      I       I 
a  little                            a  lot 

I      I      I      I      I       I 

a  little                             a  lot 

I      I      I      I 
a  little 

I       I 

a  lot 

Task  responsibility  -  Degree  of  direct,  constant  personnel  responsibility  for  completing  the  task. 

I       I      I      I      I       I 

a  little                             a  lot 

I      I      I       I      I       I 

a  little                            a  lot 

I      I      I      I 

a  little 

I       I 

a  lot 

Difficulty  to  learn  task  -  The  amount  of  time  and  effort  that  is  required  to  learn  to  mange  the  task,  relative  to  all 
other  tasks  in  the  mission. 

I       I       I       I       I        I 
a  little                             a  lot 

I      I      I      I      I       I 
a  little                             a  lot 

I      I      I      I 
a  little 

I        I 
a  lot 

Overall  importance  -  The  overall  importance  of  the  task,  relative  to  all  other  tasks  in  the  mission. 

I       I      I      I       I       I 

a  little                            a  lot 

I      I       I       I      I       I 

a  little                            a  lot 

I      I      I      I 

a  little 

I       I 

a  lot 
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PART  3:  Rationale 

1 .  Consider  the  original  organization  and  architecture  you  used  when  performing  on  the  DDD-IH 
simulation  and  compare  it  to  the  organization  and  architecture  you  have  devised  to  address  the 
event.  Rate  the  degree  of  change  or  adaption  of  the  new  organization  and  architecture  to  cope 
with  the  event. 


I1I2I3I4I5I6I7I 
very  little  a  great  deal 

2.  How  confident  are  you  that  the  organization  and  architecture  you  have  devised  will  accomplish 
the  revised  mission  caused  by  the  event? 


I1I2I3I4I5I6I7I 

very  little  a  great  deal 


3.  How  adequate  was  the  amount  of  resources  available  to  deal  with  the  event  and  the  remainder 
of  the  original  mission? 


I1I2I3I4I5I6I7I 

not  adequate  very  adequate 


4.  How  deficient  was  the  original  organization  and  architecture  PRIOR  to  the  event? 


I1I2I3I4I5I6I7I 

very  little  a  great  deal 


5.  How  deficient  was  the  original  organization  and  architecture  AFTER  the  event? 


I1I2I3I4I5I6I7I 

very  little  a  great  deal 
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ADAPTIVE  ARCHITECTURES  FOR  COMMAND  AND  CONTROL  (A2C2) 
POST-PLANNING  ASSESSMENT:  OBSERVER  RATING  FORM 

Team  ID: Date: Observer: 

Instructions  for  Post-Planning  Assessment 

Please  assess  the  post-planning  behavior  of  the  team  for  the  following  activities  using  the 
scales  provided.  Base  the  rating  on  what  you  heard  and  observed  not  on  what  you  guess  and 
think. 

1 .  To  what  extent  did  the  team  strive  to  understand  the  new  situation/mission  created  by  the 
trigger  event? 

Very  Little         12         3        4        5         6        7        A  Great  Deal 

Comments: 

2.  How  well  did  the  team  appear  to  understand  the  new/situation/mission  created  by  the  trigger 
event? 

Not  Well         12        3        4        5         6        7       Very  Well 

Comments: 

3.  How  organized  and  focused  did  the  team  appear  to  be  while  working  the  planning  task? 

Unfocused        1         2        3        4        5        6        7        Very  focused 
And  Chaotic  And  Organized 

Comments: 

4.  To  what  extent  did  the  team  address  workload  disparities  among  the  organizational  nodes? 

Very  Little         12        3        4        5         6        7        A  Great  Deal 
Comments: . _ 
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5.  To  what  extent  did  the  team  strive  to  produce  an  architecture  (organizational  structure)  that 
distributed  and  equalized  the  workload  among  the  organizational  nodes? 

Very  Little         1         2         3.       4        5         6         7         A  Great  Deal 
Comments: 


6.  Did  the  team  strive  to  produce  a  more  traditional  or  more  untraditional  architecture 
(organizational  structure)  from  the  one  they  initially  experienced? 

More         12        3        4        5        6        7        More 
Traditional  Nontraditional 

Comments: 
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A2C2  EXPERIMENT 
PLANNING  ORGANIZER  AND  PRODUCTS  BOOKLET 

Team  ID: Planning  Session: Date: 

Record  the  names  of  the  four  team  members  and  the  positions  they  played  below: 

1. 3. 


WHEN  DOING  YOUR  PLANNING:    BE  FOCUSED  —  BE  BOLD  —  BE  DECISIVE 

You  are  free  to:  alter  the  authority  structure  (who  reports  to  whom),  alter  the 
communications  structure  (who  can  speak  to  whom),  reorganize  the  resources  (assets)  among  the 
nodes  (i.e.  positions),  and  change  the  tasks  a  node  or  position  is  to  perform.  In  shortchange  the 
architecture  (organizational  structure).  However,  the  number  of  nodes  or  positions  is  fixed  at 
six  (6)  and  the  amount  of  resources  are  fixed. 

The  purpose  of  the  forms  in  this  booklet  is  two-fold: 

•  To  help  you  replan  the  mission  given  the  event  and  modify  the  existing 
organization  and  architecture,  if  you  so  desire. 

•  To  record  the  different  planning  products  for  analysis. 

As  a  team  you  are  asked  to: 

•  Provide  a  brief  situation  assessment. 

•  Write  a  brief  mission  statement. 

•  Provide  diagrams  of  the  authority  and  communication  structure  (architecture). 

•  List  the  new  tasks  created  by  the  event  (if  any)  and  tasks  from  the  original  mission 
that  must  be  altered  or  reassigned.  You  are  also  asked  to  map  resources  against  the 
tasks,  state  who  will  perform  the  tasks,  sequence  the  tasks  and  estimate  how  long 
it  will  take  to  perform  each  task. 

•  Provide  a  synchronization  and  coordination  chart  indicating  the  synchronization 
among  the  tasks. 

We  strongly  request  that  you  perform  each  of  the  tasks  listed  above  as  you  go  through  the 
planning  and  designing  process  and  not  wait  until  the  end  of  the  session.  The  tasks  are  designed 
to  give  structure  to  the  planning  and  designing  process  and  to  help  you  organize  your  efforts.  We 
also  recommend  that  you  do  the  tasks  roughly  in  the  order  they  are  listed,  but  we  understand  that 
there  might  be  some  iterations  back  and  forth  between  tasks. 
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SITUATION  ASSESSMENT 

Carefully  consider  the  event  and  the  initial  mission.  What  has  happened?  What  do  you 
know?  Prepare  a  situation  assessment  brief  in  50  or  fewer  words  and  write  itin  the  space 
provided  below. 
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MISSION  STATEMENT 

After  you  and  your  team  have  come  to  an  understanding  of  the  tactical  situation,  prepare  a 
mission  statement  of  100  or  fewer  words  that  would  be  suitable  to  brief  a  commanding  officer. 
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ARCHITECTURE:      AUTHORITY 

Please  construct  what  you  would  consider  the  most  appropriate  command  architecture  for 
dealing  with  the  event.  This  should  be  done  in  the  form  of  a  wire  diagram  as  shown  in  the 
example  below. 


Example  Architecture 


Your  Architecture  Chart  Below 
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ARCHITECTURE:  COMMUNICATION 

Redraw  your  command  architecture  in  the  space  below.  On  this  diagram,  include  the 
communications  links  that  each  node  is  allowed  to  use.  For  example,  draw  lines  from  each  to  the 
other  nodes  with  whom  they  can  communicate. 


Indicate  (by  using  double  lines)  which  communications  links  are  most  crucial. 
Who  will  be  talking  to  whom  the  most? 
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TASK  GRAPH 

The  following  form  provides  a  framework  that  you  can  use  to  organize  information  about 
the  tasks  your  team  must  perform  in  this  trial.  That  is,  any  new  tasks  created  by  the  event,  plus 
any  tasks  from  the  original  mission  that  must  be  altered  or  reassigned.  Please  list  the  tasks  you 
need  to  perform,  which  team  position  or  positions  are  responsible  (using  the  same  position 
designations  used  in  the  authority  diagram)  for  performing  each  task,  and  the  resources  necessary 
to  accomplish  each  task.  Also,  indicate  the  time  sequence  the  tasks  must  be  performed  in  by 
writing  a  "1"  in  the  "sequence"  column  next  to  all  tasks  that  must  be  performed  first,  a  "2"  next 
to  the  tasks  that  must  be  performed  second,  etc.  the  duration  is  an  estimate  of  how  long  the  task 
will  take  to  complete.  Please  give  a  real-time  estimate  of  the  duration.  By  "real-time",  we  mean 
the  best  estimate  of  time  needed  to  accomplish  a  task  in  the  real  world  (not  the  simulated  world 
ofDDD). 


Sequence 

Tasks  to  perform 

Who  will  perform 
task 

Necessary  resources 

Duration 
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Sequence 

Tasks  to  perform 

Who  will  perform 
task 

Necessary  resources 

Duration 
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SYNCHRONIZATION  AND  COORDINATION  CHART  FOR  TASKS  TO  COMPLETE 

THE  MISSION 

As  a  team,  prepare  a  synchronization  chart  either  graphical  or  written  (or  a  PERT  chart) 
of  all  the  tasks  that  are  necessary  to  perform  the  mission  successfully.  The  figure  is  an 
example  of  a  graphical  chart.  Tasks  that  must  be  performed  synchronously  should  be 
depicted  at  the  same  level  or  tier  as  Tasks  2a  and  2b  of  the  example.  If  two  or  more  nodes 
must  coordinate  to  accomplish  a  task,  indicate  this  by  writing  the  coordinating  nodes  in 
the  task  bubble,  as  in  Task  3  of  the  example. 


Please  sketch  or  write  out  your 
synchronization  and  coordination 
chart  below: 


Who  will  be  coordinating  the  most  with  whom?    What  Tasks  will  require  the  most  coordination? 
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